Network Working Group G. Tomlinson Internet-Draft CacheFlow Expires: May 20, 2002 R. Chen AT&T M. Hofmann Lucent R. Penno A. Barbir Nortel Networks November 20, 2001 A Model for Open Pluggable Edge Services draft-tomlinson-opes-model-01.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 May 20, 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 specific edge service implementations of the high level-model described herein. Editor Note: Companies must submit Intellectual property statements to the IETF using regular procedures. Tomlinson, et. al. Expires May 20, 2002 [Page 1] Internet-Draft OPES Model November 2001 Abstract Content Delivery plays an important role in the overall architecture of the web. Content providers and content consumers are increasingly looking for additional services beyond basic content delivery. In particular, content providers are interested in providing value-add services that can be performed on the content. This document provides a model for Open Pluggable Edge Services (OPES), an infrastructure for adding value added service to content. The elements of a common vocabulary that defines the infrastructure of edge services are also introduced. Table of Content 1. Introduction ............................................... 3 2. OPES Model Terms ........................................... 4 3. Overlay Networks ........................................... 9 3.1 Packet Networks ............................................ 9 3.2 Content Networks Overlay ...................................11 3.3 Content Service Networks ...................................12 3.3.1 OPES: Content Service Networks .............................14 4. OPES System Relationships ..................................14 4.1 Core Component Relationships ...............................15 4.1.1 Deployment Scenarios Supported by this Model ...............16 4.1.2 OPES Intermediary ..........................................17 4.1.2.1 OPES Engine ................................................18 4.1.2.2 Local Execution Environment: The Proxylet Run-time System ..19 4.1.2.3 Remote Execution Environment: The Remote Call-out System ..19 4.2 Remote Call-out Servers ....................................20 4.3 OPES Admin Server ..........................................20 4.3.1 Authentication Services ....................................20 4.3.2 Authorization (Policy) Services ............................21 4.3.3 Accounting Services ........................................21 4.4 Surrogate Overlays .........................................21 4.5 Delegate Overlays ..........................................23 5. End-to-End Data Integrity ..................................24 5.1 Requirements for End-to-End Data Integrity .................24 5.1.1 One-party consent ..........................................24 5.1.2 IP-layer communications ....................................25 5.1.3 Notification ...............................................25 5.1.4 Non-blocking ...............................................25 5.1.5 Privacy ....................................................25 6. Security Considerations ....................................26 6.1 Threats to the underlying Content Network ..................27 6.2 Threats to the OPES Edge Services Network ..................27 6.3 Threats to the Local Execution Environment .................27 6.4 Threats to the Remote Execution Environment ................28 7. Acknowledgements ...........................................28 References .................................................28 Tomlinson, et. al. Expires May 20, 2002 [Page 2] Internet-Draft OPES Model November 2001 1. Introduction Content Delivery is of increasing importance to the overall Architecture of the web. Content providers and content consumers are increasingly looking for enhanced services beyond basic content delivery. In particular, they are interested in providing value-add services that operate on content on its way between the content origin and content consumer. Such services are termed "Content Services". Examples of content services include: dynamic content assembly, content personalization, virus scanning, and content adaptation for different device types [11]. While some such services are already being offered by web servers or by client software, there are good reasons to develop an overlay infrastructure that support the provisioning of content services in a distributed manner. We will refer to such an infrastructure as Content Service Network (note that Edge Service Network has also been used in previous documents). The development of content service networks addresses some of the problems that current providers of content services are facing. In particular, providing content services only at a central web server, for example, entails the well-known risk of server overload, increased network load, high service latency and availability. On the other hand, providing content services only at the client might not always be an option, since 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. In other words, this is a problem of intelligence, where intelligence in the network will reside. In theory we could put all kinds of features in routers or end clients, but this doesn't scale. On the other hand, content service networks are layered onto an underlying network, in most cases an IP network, and offer content services that provide a value-add to the content being delivered. Content service networks provide services that operate on messages that are passing through the underlying network. The introduction of content service networks requires the development of mechanisms that guarantee the integrity of the content in transit in the Internet between client/intermediary, intermediary/intermediary, and intermediary/origin server. The introduction of content service networks must not violate and must protect the end-to-end data model of the Internet as described by the IAB in [18]. Tomlinson, et. al. Expires May 20, 2002 [Page 3] Internet-Draft OPES Model November 2001 The document presents a vocabulary for use in developing content service networks and describes the core components of such, and their relationships. Section 2 introduces the terms used for elements of an content service network and explains how those terms are used. Section 3 explains the concept of overlay networks and how different types of such are built upon each other. The core OPES components and their relationship are introduced in Section 4. In Section 5, the requirements for end-to-end data integrity are discussed, while security considerations are discussed in Section 6. 2. OPES Model Terms The section provides 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 required dependency on HTTP or web caching technology. This vocabulary is 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[10] 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. Tomlinson, et. al. Expires May 20, 2002 [Page 4] Internet-Draft OPES Model November 2001 CLIENT (reference definition [4]) A program that establishes connections for the purpose of sending requests. CONDITION A form of a policy condition [10] 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, 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. CONTENT SERVICE NETWORK An overlay network of 'intermediaries' layered onto an underlying network that incorporate 'content services' that operate on messages flowing through the 'content path'. 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'. Tomlinson, et. al. Expires May 20, 2002 [Page 5] Internet-Draft OPES Model November 2001 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 [14]. 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 content services network'. 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' on 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'. Tomlinson, et. al. Expires May 20, 2002 [Page 6] Internet-Draft OPES Model November 2001 ORIGIN SERVER (reference definition [4]) 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 [15] 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'. POLICY DECISION POINT (reference definition [10]) A logical entity that makes policy decisions for itself or for other network elements that request such decisions. POLICY ENFORCEMENT POINT (reference definition [10]) A logical entity that enforces policy decisions. PROXYLET A proxylet is a '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'. Tomlinson, et. al. Expires May 20, 2002 [Page 7] Internet-Draft OPES Model November 2001 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 which runs 'OPES service modules' as the result of a 'remote call-out'. ROLE (reference definition [10]) 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 [10] 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 [10] that contains a set of 'rules' and information about the rule module owner. Tomlinson, et. al. Expires May 20, 2002 [Page 8] Internet-Draft OPES Model November 2001 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. 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. 3. Overlay Networks 'Content Service networks', of which OPES is a form, rely on underlying Networks as a platform to provide transport services. Content service networks utilize the relatively new 'overlay network' paradigm. Overlay networks are a powerful abstraction that create a virtual network of connected devices layered on an existing underlying network in order to present application level services. Since OPES is based on 'overlay network' architectures, the discussion will begin with them. 3.1 Packet Networks We begin with a brief overview of Packet Networks. Packet Networks are physical networks comprised of routers and other network elements including link devices. Of particular interest to OPES are IP [1] based packet networks, including the Internet itself. IP networks form the base infrastructure onto which 'overlay networks', including OPES Content Service Networks will be layered. Tomlinson, et. al. Expires May 20, 2002 [Page 9] Internet-Draft OPES Model November 2001 +--------+ / Client / +--------+ ^ / v _______________(X)___________________ / Router / / / +--------+ / IP / +-------+ / Client /<->(X) Packet Network (X)<->/ Origin / +--------+ / / / Server / / / +--------+ /_________________(X)_________________/ ^ / v +--------+ / Client / +--------+ Figure 1. IP Packet Network Note: underlying links and internetwork boundaries are omitted for simplicity. Figure 1 depicts a diagram of an IP based Packet Network. The figure represents the classic Internet model. Here, 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. The end-to-end model has proven to be very successful. However, as we shall see in subsequent sections, there is 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. Tomlinson, et. al. Expires May 20, 2002 [Page 10] Internet-Draft OPES Model November 2001 3.2 Content Networks Overlay As the scale and reach of IP packet networks, particularly the Internet, has grown, a number of applications such as content delivery, the world wide web and streaming media did not always scale with the end-to-end model of the Internet. This is due to network congestion and the cumulative latency of internetworking. Essentially, network latency can cause unacceptable levels of jitter and packet loss that reduce the quality of streaming media. It also adds to the delay times for web applications, often to the point, that the quality of delivery is unacceptable to recipient. In order to address the above problems several new technologies such as Diffserv and MPLS have been proposed. Diffserv and MPLS aim towards providing some form of QoS or traffic engineering across the network, such that the quality of delivery of content to the end user is guaranteed. Content networks on the other hand consists of using intermediaries in the network for the delivery of content in a close proximity to the content consumer. These overlay networks create a virtual overlay on top of IP packet networks, that via 'intermediaries' enables the necessary network infrastructure to provide better content delivery services. Figure 2 contains a diagram of an Content Network Overlay. In this model in which content engine 'intermediaries' (e) are added, each application device continues to be connected to the IP packet network via router elements (X). The content engines collectively form a network overlay in which they service requests on behalf of 'origin servers'. In this model, the 'Clients' establish a session with a content engine (e) in the content path 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 content engine 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 content engines 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. Tomlinson, et. al. Expires May 20, 2002 [Page 11] Internet-Draft OPES Model November 2001 Fundamentally there are two forms of content engines, the 'delegate' and the 'surrogate'. 'Delegates', are authorized agents 'intermediaries' that act on behalf of 'clients'. Surrogates on the other hand, are authorized agent 'intermediaries' that act on behalf of 'origin servers'. Content engines are strategically placed in the 'content path' and as such are ideal platforms for 'content services'. We will discuss how they are used as the base infrastructure upon which content service networks are overlaid in the next section. +--------+ / Client / +--------+ ^ / v ____________________(e)_________________ / Content / / engine / +--------+ / /__ / Client /<->(e) Content Network / / +--------+ / / / / / / / / / +-------+ /___________________(e)_________________/ (X)<->/Origin / / ^ / / Server/ / | Packet Network / +-------+ /___________________(X)_________________/ ^ / v +--------+ / Client / +--------+ Figure 2. Content Network Overlay 3.3 Content Service Networks Content service networks provide services that act on content flowing through the 'content path'. This value-added processing of the content is known as 'content services'. Tomlinson, et. al. Expires May 20, 2002 [Page 12] Internet-Draft OPES Model November 2001 Content service networks are a specialized form of application network Overlays. Content service networks are constrained to provide services only on the 'content path', as opposed to general applications. Content 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'. Figure 3 contains a model of Content Services Network Overlay. In the model 'clients' establish a session with a content engine (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 (ag) 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: Content Service Networks OPES is a form of 'edge (i.e. content) service network'. OPES utilizes 'surrogates' and 'delegates' as 'OPES intermediaries' that provide pluggable edge services. OPES also adds additional network elements to its overlay that include administration and 'remote call-out' processing. Additionally, an OPES content 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'. Tomlinson, et. al. Expires May 20, 2002 [Page 13] Internet-Draft OPES Model November 2001 +--------+ / Client / +--------+ ^ / v _________________(i)___________________ / intermediary / / content services / +--------+ / /___ / Client /<->(i) Content Services Network Overlay / / +--------+ / (ag)/ / / (ag) / /___ /___________________(i)_________________/ / / / . / / / . Content Network / / +-------+ /___________________(e)__________________/ (X)<->/ Origin / / ^ / / Server / / | Packet Network / +--------+ /___________________(X)___________________/ ^ / v +--------+ / Client / +--------+ Figure 3. Content Services Network Overlay 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 content services network'. When such effective rights are granted to the OPES ' content services network' via a negotiated relationship, it is said to be in the 'authoritative domain'. In [16,17] there are more detailed discussions of these issues. 4. OPES System Relationships In this section, we propose an OPES system model that allows us to examine the core components of an OPES 'content service network' and the relationships among them in detail. We also apply this model to two content 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 May 20, 2002 [Page 14] Internet-Draft OPES Model November 2001 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 'content service network' and the relationships among them in detail. We also apply this model to two content service overlay networks: the surrogate overlay network that represents the interests of content providers and the delegate overlay network that represents the interests of 'content consumers'. Figure 4 contains a diagram of the network elements involved in the OPES Content Service System Model. 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 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 'content 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. Tomlinson, et. al. Expires May 20, 2002 [Page 15] Internet-Draft OPES Model November 2001 +-----------------+ | 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 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: Tomlinson, et. al. Expires May 20, 2002 [Page 16] Internet-Draft OPES Model November 2001 - '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'. - '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. - '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 internet access services. - '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. - '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 [11]. 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 Tomlinson, et. al. Expires May 20, 2002 [Page 17] Internet-Draft OPES Model November 2001 cache) 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. 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 +------------------------------------------------+ 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 [7]. 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): - Point 1: A request is received from the 'user agent'. Tomlinson, et. al. Expires May 20, 2002 [Page 18] Internet-Draft OPES Model November 2001 - Point 2: A request is about to be forwarded to the 'origin server'. - Point 3: A response has just arrived from the 'origin server'. - 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 'content services network' see [12]]. 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 are considered In-path. 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 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 'OPES engine' and a 'remote call-out server'. Typical call-out protocols include ICAP [8] and SOAP [9]. Remote operations run Out-of-path. Tomlinson, et. al. Expires May 20, 2002 [Page 19] Internet-Draft OPES Model November 2001 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. Editor Note: How does this relate to end-to-end encryption? Also, we need to consider intermediary terminated encryption. 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 typically 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 ' content services network'. 4.3.1 Authentication Services Authentication services provide authentication of devices comprising an OPES ' content 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'. Tomlinson, et. al. Expires May 20, 2002 [Page 20] Internet-Draft OPES Model November 2001 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[13]. Provisioning of these kinds 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 'content 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' 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'. Tomlinson, et. al. Expires May 20, 2002 [Page 21] Internet-Draft OPES Model November 2001 ********************************************* * * * +--------+ 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 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 [11]. Tomlinson, et. al. Expires May 20, 2002 [Page 22] Internet-Draft OPES Model November 2001 4.5 Delegate Overlays A delegate overlay is a specific type of 'content 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'. +--------+ | Origin | | Server | +--------+ | | | ********************************************* * | * * +--------------+ +-----------------+ * * | OPES |----- | Remote Call-out | * * | Intermediary | | Server | * * +--------------+ +-----------------+ * * | \ * * | +------------+ * * | | OPES Admin | * * | | Server | * * | +------------+ * * +--------+ * * | Client | Authoritative * * +--------+ Domain * * * ********************************************* Figure 7. Authoritative Domains for Delegate Overlays Tomlinson, et. al. Expires May 20, 2002 [Page 23] Internet-Draft OPES Model November 2001 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). More information on Delegate scenarios see [11]. 5. End-to-End Data Integrity The architectural principles of OPES type devices and content service networks must protect the end-to-end data integrity in the Internet. In particular, the robustness long cited as one of the overriding goals of the Internet architecture [19] must be respected. These concerns were addressed by the IAB in [18] and by OPES in [20]. In [16,17], a framework for ensuring the data integrity, security and privacy for OPES based networks are discussed. This section discusses the guidelines that must be followed during the design of content services networks to ensure that the end-to-end data integrity is achieved. The work does not develop specific model or protocols. However, the guidelines may require the development of new approaches that could be used to ensure the integrity of data in networks with distributed intelligence. 5.1 Requirements for End-to-End Data Integrity The design of OPES intermediaries and any overlay networks that are based on such devices must be based on the requirements that are discussed next. 5.1.1 One-party consent The use of any OPES service must be explicitly authorized by AT LEAST one of the application-layer end-hosts. This means that either the content provider or the client or both must explicitly agree on the OPES service. This can be achieved through the following [20]: - An extensible content providers "Permissions" format for use by content providers must be defined indicating what parts of content can be modified and what modifications are allowed. This must allow different permissions for different resources. Tomlinson, et. al. Expires May 20, 2002 [Page 24] Internet-Draft OPES Model November 2001 - A means for OPES Intermediaries to fetch Content Providers Intermediaries Permissions documents must be provided. - A means for content provider to decline the services of an OPES Intermediaries. 5.1.2 IP-layer communications The presence of OPES Intermediaries MUST NOT be hidden from the user or the client (i.e. content consumer). In this regard, the client and/or the content provider must be able to explicitly address the OPES Intermediaries at the IP layer. 5.1.3 Notification Implementers of OPES Intermediaries should assist content providers in developing schemes that enable them to detect inappropriate behavior of such devices. This can be achieved through the use of the following: - Developing a format for use at a Web site to associate digital signatures with parts or all of the content. This can enable content consumers (end user or client) to check/verify content integrity to ensure parts of content not intended to be transformed have been left unchanged. An example of such method is given in [17]. Similarly, it is possible to use a scheme that is similar to W3C Signatures [21]. - A mechanism for creating temporary versions of the integrity check format for dynamically created content should be developed. - A mechanism should be developed to allow end users (i.e. content consumers) (or others) to retrieve integrity checking information for resources from a Web Site. One mechanism for retrieving this information is placement at a well-known place on the Web site (similar to P3P [22]). 5.1.4 Non-blocking The design of OPES Intermediaries must allow end users to request and receive a Non OPES version of the content if available. To fulfill this requirement extensions to current schemes for requesting data may be required. Editor Note: Need to incorporate that specific rules might also be an approach to address this issue. For example, IRML allows the specification of "negative rules", i.e. if a certain condition matches, do NOT do the listed actions. A content provider could specify such rules for his/her non-OPES versions (e.g. if URL is for non-OPES version, never do OPES service). Tomlinson, et. al. Expires May 20, 2002 [Page 25] Internet-Draft OPES Model November 2001 5.1.5 Privacy OPES Intermediaries must respect the following rule regarding privacy - OPES Intermediaries must not violate a Web site's W3C P3P policy applicable to a resource (P3P policy are found at the Content Providers Web Site). - OPES Intermediaries must honor both End User (i.e. content consumer) and Content Provider Intermediaries Privacy policies. Furthermore, as discussed in [20], appropriate schemes should be developed that allow: - Users (i.e. content consumers) /or Content Providers to define additional privacy requirements that apply to Intermediaries in an Intermediaries Privacy policy. Note that P3P describes privacy policy end to end, but a more restrictive privacy policy may be desirable at Intermediaries. The Intermediaries Privacy Policy must include the ability to specify what information can be recorded by Intermediaries and how it is used. - Establishing a mechanism for OPES Intermediaries to access a Content Provider's Intermediaries Privacy policy. One method for Content Providers must be to place an Intermediaries Privacy policy document at a well known place on their Web site. - Establishing a mechanism for OPES Intermediaries to receive an end user's (i.e. content consumer)Intermediaries Privacy policy. - Establishing a mechanism for OPES Intermediaries to be able to specify what information Intermediaries can or cannot record, including cookies, IP addresses, HTTP header fields and how they can use that information. - Establishing a mechanism for OPES Intermediaries to be able to specify what information can or cannot be passed by OPES Intermediaries to OPES callout services, including cookies, IP addresses, HTTP header fields. - Establishing a mechanism for OPES Intermediaries to be able to specify what information has been recorded. This information must be passed to the Content Provider on requests (if required by the Content Provider's Intermediary Privacy policy) and must also be returned to the End User in responses (default, even when no End User (content consumer) Intermediaries Privacy Policy is available). - OPES Intermediaries Privacy policies must be able to specify that OPES Intermediaries should pass through requests or responses without OPES callouts. Tomlinson, et. al. Expires May 20, 2002 [Page 26] Internet-Draft OPES Model November 2001 6. Security Considerations Security concerns with respect to ' content 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'. 6.1 Threats to the underlying Content Network The OPES ' content service network' is predicated upon an underlying network to secure the 'content path'. Thus, threats to the underlying network pose threats to the OPES 'content services network'. The principal threat being the compromising of an edge server hosting an OPES Intermediary. 6.2 Threats to the OPES Content Services Network If an 'OPES admin server' is breached, the attacker can gain control of the entire OPES ' content 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 ' content 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. 6.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 May 20, 2002 [Page 27] Internet-Draft OPES Model November 2001 6.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. 7. 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, Nalin Mistry and Lily Yang. 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, . Tomlinson, et. al. Expires May 20, 2002 [Page 28] Internet-Draft OPES Model November 2001 [7] Beck, A. and M. Hofmann, "IRML: A Rule Specification Language for Intermediary Services", draft-beck-opes-irml-01.txt (work in progress), July 2001, . [8] Elson, J. and A. Cerpa, "ICAP the Internet Content Adaptation Protocol", ICAP Forum http://www.circlemud.org/~jelson/icap-1.72.txt, Work in progress, June 2001, . [9] 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, . [10] 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-04.txt (work in progress), July 2001, . [11] McHenry, S., Condry, M. and G. Tomlinson, "Open Pluggable Edge Services Use Cases and Deployment Scenarios", draft-mchenry-opes-deployment-scenarios-00.txt (work in progress), July 2000, . [12] Rafalow, L., Yang, L. and A. Beck, "Policy Requirements for Edge Services", draft-rafalow-opes-policy-requirements-00.txt (work in progress), July 2001, . [13] Nottingham, M., Tsimelzon, M., Weihl, B. and L. Jacobs, "ESI Language Specification 1.0", EDGE SIDE INCLUDES http://www.esi.org/language_spec_1-0.html, May 2001, . [14] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, "Middlebox Communication Architecture and framework", draft-ietf-midcom-framework-03.txt, work in progress. [15] R. Penno, A. Rayhan, M. Duffy, "Out-Of-Path (OOP) Agents and MIDCOM Framework Integration", draft-penno-midcom-oop-00.txt, work in progress. Tomlinson, et. al. Expires May 20, 2002 [Page 29] Internet-Draft OPES Model November 2001 [16] A. Barbir et al, " A Framework for OPES End to End Data Integrity: Virtual Private Content Networks (VPCN)", draft-barbir-opes-vpcn-00.txt, Work in Progress, November 2001, URL:http://www.ietf.org/internet-drafts/ draft-barbir-opes-vpcn-00.txt. [17] Hillary Orman, "Data Integrity in an Active Content System", http://www.cs.utah.edu/~horman/opes.html. [18] S. Floyd et al, "IAB Architectural and Policy Considerations for OPES ",draft-iab-opes-01.txt, work in progress, October 2001. URL:http://www.ietf.org/internet-drafts/draft-iab-opes-01.txt> [19] David D. Clark, The Design Philosophy of the DARPA Internet Protocols, SIGCOMM 1988. [20] Wayne Carr, ``Suggested OPES Requirements for Integrity, Privacy and Security'', email to ietf-openproxy@imc.org, August 16, 2001. URL ``http://www.imc.org/ietf-openproxy/ mail-archive/msg00869.html''. [21] Eastlake, D., Reagle, J., Solo, D., Bartel, M., Boyer, J., Fox, B., LaMacchia, B. and E. Simon, "XML-Signature Syntax and Processing", W3C Proposed Recommendation, work in progress, August 20001, URL:http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/> [22] Cranor, L., Langheinrich, M., Massimo, M., Presler-Marshall, M. and J. Reagle, "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", W3C Note, work in progress, September 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 May 20, 2002 [Page 30] Internet-Draft OPES Model November 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 Reinaldo Penno Nortel Networks, Inc. 2305 Mission College Boulevard Building SC9-B1240 San Jose, CA 95134 Email: rpenno@nortelnetworks.com Abbie Barbir, Ph.D. Nortel Networks 3500 Carling Avenue Nepean Ontario K2H 8E9 Canada Email: abbieb@nortelnetworks.com Tomlinson, et. al. Expires May 20, 2002 [Page 31] Internet-Draft OPES Model November 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 May 20, 2002 [Page 32]