Network Working Group G. Tomlinson Internet-Draft H. Orman Expires: January 11, 2001 Novell M. Condry J. Kempf Sun Microsystems D. Farber Digital Island July 13, 2000 Extensible Proxy Services Framework draft-tomlinson-epsfw-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 11, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract In today's Internet, caching proxies that intermediate between HTTP (and increasingly streaming media) clients and servers provide enhanced performance for Web page access. Both clients and servers are increasingly looking to the network for additional services that can't be provided directly on the client or server, and Web proxies are an attractive place for locating these services. In fact, some such services (content assembly for advertising) are already being offered by Web proxies for servers, but in a nonstandard way. This document Tomlinson, et. al. Expires January 11, 2001 [Page 1] Internet-Draft Ext. Proxy Services FW July 2000 describes the problem and solution requirements for a standardized, open and extensible service environment on caching proxies which enables them to provide general services that mediate, modify, and monitor object requests and responses. It introduces an architectural framework along with a set of core requirements necessary to design standardized implementations for this application domain, taking into account relevant IETF RFCs and IETF work-in-progress. The architecture and requirements described here are mindful of the success of end-to-end nature of Internet client/server interactions, and the consequences of the proposed architectural changes on end-to-end semantics are discussed. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Requirement Language . . . . . . . . . . . . . . . . . . . 4 1.2 Relationship to other IETF Work . . . . . . . . . . . . . 4 1.3 Relationship to known work outside IETF . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Problem Description and Goals . . . . . . . . . . . . . . 10 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . 11 5. Service Execution Environment Requirements . . . . . . . . 14 5.1 Rule Base Requirements . . . . . . . . . . . . . . . . . . 14 5.1.1 Message Parser . . . . . . . . . . . . . . . . . . . . . . 14 5.1.2 Message Property . . . . . . . . . . . . . . . . . . . . . 15 5.1.3 Rule Base . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.4 Rule Processor . . . . . . . . . . . . . . . . . . . . . . 16 5.2 Execution Environment Requirements . . . . . . . . . . . . 16 5.2.1 Service Management . . . . . . . . . . . . . . . . . . . . 16 5.2.2 Resources and functions of the caching proxy . . . . . . . 17 5.2.2.1 Resources . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.2.2 Functions . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3 Proxylet Requirements . . . . . . . . . . . . . . . . . . 18 5.4 Remote Callout Requirements . . . . . . . . . . . . . . . 19 5.5 Network Access Requirements . . . . . . . . . . . . . . . 19 6. Proxy Discovery . . . . . . . . . . . . . . . . . . . . . 21 7. Security Requirements . . . . . . . . . . . . . . . . . . 23 7.1 Authorization, Authentication, and Accounting Requirements . . . . . . . . . . . . . . . . . . . . . . . 23 7.1.1 AAA in the Existing Web System Model . . . . . . . . . . . 24 7.1.2 Service Environment Caching Proxy AAA Requirements . . . . 25 7.1.3 Remote Callout Server AAA Requirements . . . . . . . . . . 27 7.1.4 Administrative Server AAA Requirements . . . . . . . . . . 29 7.2 Requirements on the Service Execution Environment . . . . 30 8. Impact on the Internet Architecture . . . . . . . . . . . 32 9. Intellectual Property . . . . . . . . . . . . . . . . . . 35 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 36 Tomlinson, et. al. Expires January 11, 2001 [Page 2] Internet-Draft Ext. Proxy Services FW July 2000 References . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 39 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 41 A.1 Request Identification . . . . . . . . . . . . . . . . . . 41 A.2 Content Assembly . . . . . . . . . . . . . . . . . . . . . 41 A.3 Multimedia Stream Management . . . . . . . . . . . . . . . 42 A.4 Virus Detection . . . . . . . . . . . . . . . . . . . . . 42 A.5 Transcoding . . . . . . . . . . . . . . . . . . . . . . . 43 Full Copyright Statement . . . . . . . . . . . . . . . . . 44 Tomlinson, et. al. Expires January 11, 2001 [Page 3] Internet-Draft Ext. Proxy Services FW July 2000 1. Introduction Caching proxies are important elements contributing to the scalability and management of content services on the Internet today. They are used to accelerate Web sites, to reduce traffic over expensive transoceanic links, and to reduce latency for groups of users in enterprises or at ISP sites. Increasingly, caching proxies are being used for additional services, for example, content assembly for advertising. Both end users and Web publishers are looking to caching proxies as a potential platform for deploying other services that can't be deployed in clients or servers. There are a variety of existing or proposed protocols that implement particular services or network components for implementing services. NECP [16] handles aspects of control of proxy configuration and topology. ICAP [7] handles transport of Web objects to content modification servers and back. The number of such proposals is likely to grow over time. Consequently, an architecture and core set of requirements to guide standardization of proxy enhancements are desirable. This document describes an architecture and requirements for extending the functionality of a caching proxy to provide general services that mediate, modify, and monitor object requests and responses. The effect of these changes on the end-to-end nature of client/server interactions in the Internet are also discussed. 1.1 Requirement Language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in RFC2119 [10]. 1.2 Relationship to other IETF Work The authors have explicitly framed it with respect to the documented taxonomy of [9] web replication and caching. Readers are encouraged to become familiar with this taxonomy as it provides a baseline context for this application domain. The authors have also attempted to frame it with respect to IETF standards (both existing and known work-in-progress) for security[1][5]; accounting, authorization and authentication [8][12]; policy [13]; and end to end model architectural principles [14][15]. Tomlinson, et. al. Expires January 11, 2001 [Page 4] Internet-Draft Ext. Proxy Services FW July 2000 1.3 Relationship to known work outside IETF The framework has taken into account known work [7] being done outside the IETF that it is considered to be relevant to the application domain. Tomlinson, et. al. Expires January 11, 2001 [Page 5] Internet-Draft Ext. Proxy Services FW July 2000 2. Terminology This section contains a list of terms from existing IETF documents (identified by reference number), and new terms specific to this document. avatar A caching proxy located 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. cache [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 [9] 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. content server The server on which content is delivered from. It may be an origin server, replica server, surrogate or parent proxy. inbound/outbound [4] Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", and "outbound" means "traveling toward the user agent". interception proxy (a.k.a. "transparent proxy", "transparent cache") [9] The term "transparent proxy" has been used within the caching community to describe proxies used with zero configuration within the user agent. Such use is somewhat transparent to user agents. Due to discrepancies with [4] (see definition of "proxy" above), and objections to the use of the word "transparent", we introduce the term "interception proxy" to describe proxies that receive redirected traffic flows from network elements performing traffic interception. Tomlinson, et. al. Expires January 11, 2001 [Page 6] Internet-Draft Ext. Proxy Services FW July 2000 Interception proxies receive inbound traffic flows through the process of traffic redirection. (Such proxies are deployed by network administrators to facilitate or require the use of appropriate services offered by the proxy). Problems associated with the deployment of interception proxies are described in the companion document "Known HTTP Proxy/Caching Problems"[19]. The use of interception proxies requires zero configuration of the user agent which act as though communicating directly with an origin server. non-transparent proxy See "proxy". origin server [4] The server on which a given resource resides or is to be created. proxy [4] An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies. proxylet Executable code modules that have a procedural interface to the caching proxy's core services. Proxylets may be either downloaded from content servers or user agents, or they may be preinstalled on the caching proxy. proxylet library A language binding dependent API on the service environment caching proxy platform with which proxylets link. This provides a standardized and strictly controlled interface to the service execution environment on the proxy. remote callout server A cooperating server which runs services as the result of network protocol messaging interactions to/from a service Tomlinson, et. al. Expires January 11, 2001 [Page 7] Internet-Draft Ext. Proxy Services FW July 2000 environment caching proxy. rule module A collection of message pattern descriptions and consequent actions that are used to match incoming protocol messages and process their contents if a match occurs. service [11] Work performed (or offered) by a server. This may mean simply serving simple requests for data to be sent or stored (as with file servers, gopher or http servers, e-mail servers, finger servers, SQL servers, etc.); or it may be more complex work, such as that of irc servers, print servers, X Windows servers, or process servers. Note: Unqualified use of the term "service" within this memo is constrained to represent work performed on the network traffic flowing through the caching proxy. service environment caching proxy A caching proxy which has functionality beyond the basic short-circuit request fulfillment, making it capable of executing extensible (programmable) services, including network transactions with other hosts for purposes of modifying message traffic. service execution environment The environment on the caching proxy that allows new services to be defined and executed. surrogate [9] 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 Tomlinson, et. al. Expires January 11, 2001 [Page 8] Internet-Draft Ext. Proxy Services FW July 2000 surrogates. transparent proxy See "proxy". trigger A rule that matches a network protocol message, causing a proxylet to execute or other action to occur on the matched message segment. user agent [4] The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools. 2.1 Discussion The most common use of caching proxies is to short-circuit HTTP requests by fulfilling them from a cache store. When the caching proxy is dedicated to particular source server sites, it is called a surrogate. When it is dedicated primarily to a group of users it is called an avatar. Avatars that act as caching proxies regardless of the user browser configuration are also called interception proxies. It is possible for a single instance of a caching proxy to fulfill all these roles. It is also possible for a caching proxy to be a surrogate for many sources or to be an avatar for users that belong to different naming or trust domains. Surrogates today have the most elaborated services environment. Surrogate services are used to implement content assembly for advertising. Such modifications have yet to be fully specified, however. Tomlinson, et. al. Expires January 11, 2001 [Page 9] Internet-Draft Ext. Proxy Services FW July 2000 3. Problem Description and Goals The fundamental problem that a service environment caching proxy must solve is how to perform modifications on HTTP and other protocol messages flowing upstream/downstream in a way that both maintains good network performance for request fulfillment and allows flexible definition of new services. The architecture provides the framework for solutions to this problem. Since performance is a key determinant, the architecture cannot simply be restricted to network protocols that allow remote callout servers to perform these services (such as [7]), because some simple services can be executed more quickly on the service environment caching proxy itself. Similarly, the architecture cannot simply be restricted to proxylets executing on the proxy, since there are some services (virus checking is an example) that could require more or a different kind of execution resource than is available on the proxy. The need for flexibility of service definition suggests that the functionality provided by the service execution environment on the proxy cannot be specified in advance; rather, the need is for an extensible platform that can be enhanced by downloading proxylets from user agents or content servers. If a service environment caching proxy is to allow downloading of rule modules and proxylets from user agents and content servers, the proxy requires some mechanism whereby it can authenticate that a host attempting an upload is authorized to perform the upload, and to verify that the uploaded proxylet is valid. The proxy must also be able to generate accounting records, potentially across administrative domains, that allow the owners of the proxy to collect for services rendered on the proxy. Interactions with remote callout servers also require authentication and accounting. While executing on the proxy, proxylets from separately authorized parties must be protected from interfering with each other. These constitute the security requirements for the service environment caching proxy. Tomlinson, et. al. Expires January 11, 2001 [Page 10] Internet-Draft Ext. Proxy Services FW July 2000 4. Architecture Figure 1 contains a diagram of the network elements involved in the service environment caching proxy architecture. +-----------------+ | RC | | | | Remote Callout | | Server | | | | | +-----------------+ A | | | | | | V +----------+ +-------------------+ +---------------+ | UA |<------|4 P 3|<-----------| S | | | | | | | | User |------>|1 Caching Proxy 2|----------->| Content | | Agent | | | | Server | +----------+ |-------------------| +---------------+ | Service | | Execution | | Environment | +-------------------+ A | | | | | | V +-----------------+ | A | | | | Administration | | Server | | | | | +-----------------+ Figure 1 System Architecture Components There are 5 major network components: 1. The user agent (UA) represents any client: PC, wireless, etc; the client makes requests for content service with requests going through the proxy server Tomlinson, et. al. Expires January 11, 2001 [Page 11] Internet-Draft Ext. Proxy Services FW July 2000 (P) for potential cache hits. 2. The caching proxy server (P) represents the proxy server where the service execution environment is implemented. Services in the Proxy Service Execution Environment are defined with Proxylets and Rule Modules together with general services provided by the Proxylet Library. The four execution points (1-4) represent locations in the round trip message flow where an event trigger can occur, resulting in a proxylet processing the message. These execution points are: Point 1: Client Request represents the client (UA) request to the caching proxy (P) on the inbound flow. Point 2: Proxy Request represents the caching proxy (P) request to the content server (S) on the inbound flow. Point 3: Content Response represents the response from the content server (S) to the caching proxy (P) on the outbound flow. Point 4: Proxy Response represents the caching proxy (P) response to the client (UA) on the outbound flow. 3. The Content server (S) is the source of content for the caching proxy. 4. The Remote Callout Server (RS) offers remote service execution. The Proxy initiates processing on the Remote Callout Server, and receives the results for potential caching and transmission to/from the User Agent or Content Server. 5. The Administrative Server (A) performs the downloading of proxylets at a higher trust level, the collection of accounting and log data, and other administrative tasks on the service environment caching proxy. Although only one proxy is shown in the diagram, serving as both a surrogate and an avatar, a service environment caching proxy can serve in either or both of these roles. In addition, it is possible that proxies can be chained, so that a request may traverse a number of proxies before reaching the end of the inbound or outbound connection. Tomlinson, et. al. Expires January 11, 2001 [Page 12] Internet-Draft Ext. Proxy Services FW July 2000 In its unprogrammed state, the service environment caching proxy accepts request messages and generates reply messages in the manner of a traditional caching proxy. By programming the service environment caching proxy, additional value added services may be introduced. Programming occurs by introducing proxylets and rule modules into the service environment caching proxy. Such introduction can occur either directly, through the administrative server, or through callouts in the message stream that cause downloading of proxylets and rule modules from the content server or user agent. The new elements of the service environment caching proxy are message parsers, a rule processor, and a set of actions. The service environment caching proxy may support proxylets authored in one or more programming languages (for example, Java, PERL, etc.). A message parser appropriate to the protocol of the message being examined processes the message stream flowing between the user agent and the content server, extracting message properties relevant to the rule base. The message properties are then fed through the rule processor with the appropriate rule module. A rule is matched if the message properties match those specified in the rule. The matching of a rule results in a trigger that causes an action to occur. The action may be the execution of a proxylet, an action built into the proxylet library, or a callout to a remote callout server for help processing the message. Salient components of the message are passed to the proxylet, built-in action function, or, via a network protocol, to the remote callout server. Proxylets, built-in actions, or remote callout servers may inspect, add, delete, and modify the properties of messages identified by message parsers, within constraints defined by the message parser. The results of processing are passed back to the service execution environment for disposal. The actual action taken by the service execution environment may be to cache the result, or to throw it away and send an error message to the user agent or content server. After action execution is completed, the service execution environment performs no other modification on the message. Tomlinson, et. al. Expires January 11, 2001 [Page 13] Internet-Draft Ext. Proxy Services FW July 2000 5. Service Execution Environment Requirements Combining the goals in Section 3 with the architecture described in Section 4 results in a set of requirements on the service execution environment. 5.1 Rule Base Requirements 5.1.1 Message Parser A message parser is responsible for interpreting messages received, isolating salient elements as message properties, and causing actions to be activated when appropriate. When a trigger occurs, an event context is established containing the relevant properties isolated by the message parser. Any supported protocol MUST have a corresponding message parser. A parser MAY contain subordinate parsers that correspond to subordinate protocols. For example, within an HTTP message parser there may be separate parsers for handling different MIME types such as HTML, XML, and XHTML. From the standpoint of the rule processor, all parsers look like a single engine. The API for message parsers SHOULD be defined so that parsers for new protocols and content can be added modularly. For any protocol to be supported by the service environment caching proxy, the interface between the protocol's message parser and the rule base MUST be elaborated by defining: 1. The set of properties defined by the message parser, including the property name, its relationship to the message it characterizes, and the ability of an action to modify it. 2. The points in Figure 1 at which rules are be activated. A service environment caching proxy MUST provide a means by which an external process can determine whether a given message parser interface is supported. A message parser SHOULD parse a message in a single pass. Note: The authors recommend single pass parsers to meet the performance requirements anticipated for general usage. A message parser MUST always terminate when processing a finite message, independent of message content. Tomlinson, et. al. Expires January 11, 2001 [Page 14] Internet-Draft Ext. Proxy Services FW July 2000 5.1.2 Message Property Each message property consists of a message property name and a message property value. The value may be determined by the message. Some example message property names: httpRequest.url the value of the request-URI in the request line of an HTTP request. httpRequest.host the value of the "host:" header in an HTTP request. httpReply.html.embeddedURL the value of an embedded URI within the text of an HTTP document. Other message properties may be defined to provide the context in which the embedded URI occurs. rtspRequest.url the value of the request-URI in the request line of an RTSP request. 5.1.3 Rule Base A rule base consists of a collection of rule modules. Each rule module consists of a collection of rules. Each rule consists of a pattern and an action. A pattern is an expression that can be evaluated with respect to the message properties in an event context, and either the rules will match or fail to match the properties in the context. Actions identify proxylets, built-in proxy library functions or remote callouts that can modify the unmediated operation of the service environment caching proxy. Every rule module has an owner, identified by the source of the module. The trust relationship between the proxy and the owner MAY be at varying levels. Some rule modules MAY be allowed to perform actions that others aren't, for administrative or other purposes. The format of a rule, its constituent patterns and actions MUST be specified. The format of a rule module SHOULD be specified as an XML DTD. The syntax of a pattern MUST include a way to identify and match properties specified by message parsers. Tomlinson, et. al. Expires January 11, 2001 [Page 15] Internet-Draft Ext. Proxy Services FW July 2000 The syntax of an action MUST be the name of proxylets, built-in proxy library function or remote callouts. There MUST be a way to associate a rule module with a single owner. There SHOULD be a way to associate a rule module with the location and version of the proxylet library (or libraries) to which it refers. A service environment caching proxy MAY accept one or more rule modules that are applicable to all requests. Such a rule module may be required for administrative purposes. A service environment caching proxy MUST define a method for installing and updating rule modules. The service environment caching proxy SHOULD define a method to allow any external domain that it may proxy to dynamically load or update a rule module. 5.1.4 Rule Processor The rule processor is a form of dispatcher, invoked by a message parser at an event, and responsible for activating applicable rules in a rule base. The rule processor activates a rule by determining whether the rule's pattern matches the event properties in a given event context, and if so, invoking the corresponding action. 5.2 Execution Environment Requirements The service environment caching proxy MUST present an interface for managing services and for making use of the resources of the caching proxy. 5.2.1 Service Management The administrator of a caching proxy MUST be able to specify the policy for accepting new services and for determining their rights and privileges. The service management interface MUST support manual loading of rules and proxylets by a system administrator. The interface MUST support the deletion of rules and proxylets, listing of the all rules and proxylets and their status. The interface MUST support policy regarding extending the service environment. Rules and proxylets MAY be loaded by a service. The proxylet library MUST support such loading, but local policy Tomlinson, et. al. Expires January 11, 2001 [Page 16] Internet-Draft Ext. Proxy Services FW July 2000 enforcement can deny the library request. Rules and proxylets MAY be loaded implicitly by content passing through the proxy. The proxylet library MUST support such loading, but local policy enforcement can prevent it. 5.2.2 Resources and functions of the caching proxy The execution environment must offer resources and basic functions that rules and proxylets draw on, and it must be able to limit use of those resources and the resources used by the basic functions. 5.2.2.1 Resources The fundamental resources of the caching proxy are: 1. Cached objects 2. Memory for representing the executable services 3. CPU cycles for executing the services 4. Bandwidth (incoming and outgoing) for network communication 5. Secondary storage for cached information (state information, etc.) 6. Persistent storage (for configuration information, etc.) 7. Network connections 8. Lists of object names and metadata 9. Users (lists of registered users, current users, etc.) 10. Policy relating to control of the caching proxy resources 11. Logging and accounting information The services environment MUST be able to limit the use of these resources on a per AAA policy basis to a level specified by the system administrator. 5.2.2.2 Functions The basic classes of functions provided by the caching proxy Tomlinson, et. al. Expires January 11, 2001 [Page 17] Internet-Draft Ext. Proxy Services FW July 2000 to the extensible services MUST include a minimal set of operations. This set SHOULD include operations from the following list: 1. Operations on network messages The operations will be specified in terms of the semantics of the underlying language and MUST include the ability to replace, modify, delete, or insert information. 2. Operations on cached objects 3. Operations on object names 4. Creation and operations on network connections (either client or server mode) The operations MUST include the ability to determine that response message for any incoming message 5. Operations on user objects 6. Accounting and billing operations 7. User object accesses 8. Allocation and maintenance of local state information 5.3 Proxylet Requirements Proxylets MUST be able to run on arbitrary caching proxies in an environment that gives them access to standard semantics and predictable results. It should not be necessary to write different proxylets for different types of caching proxies - the environment should provide a basic set of well-understood functions and a clear way of determining the state of additional functions. A proxylet itself may provide additional functions to other proxylets. The fundamental motivating use of proxylets is for acting as a proxy for some subclass of network requests. This functionality MUST be supported. Beyond that, proxylets are simply programs that execute on caching proxies, and their purpose may be unrelated to the basic caching or proxying services; for example, a proxylet may provide naming or identity mapping services for users. The proxylet library for a given proxylet language MUST Tomlinson, et. al. Expires January 11, 2001 [Page 18] Internet-Draft Ext. Proxy Services FW July 2000 include a way to inspect message properties. The proxylet library for a given proxylet language MUST include a way to modify message properties. The proxylet library MUST provide a way for proxies to determine the available service classes and their revision levels. The proxylet namespace MUST be standardized and global. Local handles MAY be implemented. Service environment caching proxies: o MUST provide a means by which an external server can determine whether a given proxylet language and encoding format is supported. o MUST define a method for installing and updating a library of supported proxylets. o SHOULD define a method to allow any external domain that it may proxy to dynamically load or update a proxylet library. o SHOULD provide means to limit the use of resources by a given proxylet, domain, or owner of the proxylet. o SHOULD provide means by which an operator can monitor the use of resources by proxylets associated with a given domain or owner of the proxylet. 5.4 Remote Callout Requirements Some extensible services will require additional systems for extra CPU cycles or for protecting proprietary algorithms or databases. Standard protocols for directing remote operations MUST be part of the architecture. The protocols should be able to handle self-contained or streaming data for both input and output. 5.5 Network Access Requirements If service environment proxies become common, it is likely that a single protocol message may traverse multiple proxies and undergo some degree of processing before reaching the ultimate destination. In order to preserve scalability, it is important that proxies beyond the next hop neighbor not be visible along the direction of the inbound/outbound flow. Such proxies may naturally be accessible through a separate Tomlinson, et. al. Expires January 11, 2001 [Page 19] Internet-Draft Ext. Proxy Services FW July 2000 connection, but scalability would be compromised if the results of processing on one proxy were dependent on those of another proxy beyond the next hop. This leads to the requirement: o The service execution environment components MUST avoid providing facilities that allow services to construct dependencies on proxies other than the next hop, along the inbound/outbound flow. The service execution environment MAY provide facilities that allow a service to communicate with a proxy that is not adjacent through a separate out-of-band connection. Such facilities MUST treat the connection like any other remote callout server. Tomlinson, et. al. Expires January 11, 2001 [Page 20] Internet-Draft Ext. Proxy Services FW July 2000 6. Proxy Discovery In the existing Web architecture, the process by which a client or server discovers its proxy is undefined. Although there have been attempts to standardize on how proxy discovery is performed (see [17] ), no standard has yet been put in place. Proxy discovery is basically ad hoc. Clients typically obtain their proxies from system administrators, servers by static or dynamic configuration based on the business or administrative relationships with the providers of proxy services. With the addition of service execution environment proxies, proxy discovery potentially becomes more complex. There are a number of issues involved: 1. In order to preserve the end-to-end nature of the client/server connection, the provider of a service environment proxy are encouraged to explicitly require the client or server to "log on" to the proxy, through an authentication process that may require human intervention particularly if the proxy is an avatar. If so, the current interception proxy model will require an explicit service discovery step, possibly through a URL supplied by a person, but also potentially through some automated service discovery mechanism. 2. With the addition of a service environment, proxies become unequal in the services they provide. Whereas previously proxies provided caching and nothing more, they now are able to offer an array of services some of which may be interesting to clients and servers, others of which are uninteresting. These considerations lead to a number of requirements for proxy discovery. Automated proxy discovery within a domain with authentication is provided by Service Location Protocol (SLP) [18]. SLP allows a proxy discovery client to specify a query with attributes describing the services provided by the proxy and a service type describing the service. Responses to the proxy discovery query contain the URLs of proxies that match the attributes. If authentication is enabled, the response contains a digital signature enabling the proxy discovery client to verify trustworthiness of the URL source. Since SLP was explicitly designed for attribute based service discovery, the following requirement is suggested: Tomlinson, et. al. Expires January 11, 2001 [Page 21] Internet-Draft Ext. Proxy Services FW July 2000 o Within administrative domains, SLP MAY be used for locating service environment proxies by the services they provide. If authentication of the proxy URL is required, SLP authentication SHOULD be used. Between administrative domains, there is currently no way to discover services based on their characteristics. This suggests the following requirement for inter-domain service discovery. o Between administrative domains, a mechanism for locating a service environment proxy based on the services it provides SHOULD be developed. Authentication of the proxy URLs provided MUST be part of the design. Finally, if discovery based on services offered is not an issue, clients or servers can either be statically or dynamically configured with proxy URLs, and, correspondingly, proxies can be configured with their upstream and downstream peers, if there are intermediate proxies. Any of a variety of existing IP protocols can be used for dynamic configuration. Authentication on dynamically discovered proxies is, however, essential: o When discovery by service offered is not required, the service discovery mechanism used MUST supply an authentication mechanism whereby the discovering client can verify the trustworthiness of the source supplying the service environment caching proxy information. Tomlinson, et. al. Expires January 11, 2001 [Page 22] Internet-Draft Ext. Proxy Services FW July 2000 7. Security Requirements Security requirements for the service environment caching proxy break into two broad areas: 1. Authentication, authorization, and accounting requirements above and beyond those currently a part of HTTP, to ensure that the trust relationships between the caching proxy and its upstream and downstream peers, any remote callout servers, and any administration servers are validated and that the proper accounting records are generated so that the owners of the caching proxy can bill for services rendered. 2. Requirements on the service execution environment to allow proxylets and rule sets from multiple different parties to run without the possibility of unintentional or malicious interference. The next two subsections discuss these topics in more detail. 7.1 Authorization, Authentication, and Accounting Requirements The authorization, authentication, and accounting (AAA) requirements for the service environment caching proxy are driven by a need to ensure authorization of a client, publishing server or administrative server attempting to inject proxylet functionality, to authenticate injected proxylets, and to perform accounting on proxylet functions so the client or publishing server can be billed for the services. In addition, AAA is also required for a host willing to act as a remote callout server. Figure 2 contains a diagram of the trust relationships between the different entities in the service environment caching proxy architecture. T2 +-------------------+ | T7 T5 | | +------RC ----+ | | / | \ | |/ T1 T4| T3 \| C ------- P ------- S T6| A Figure 2 AAA Trust Relationships Tomlinson, et. al. Expires January 11, 2001 [Page 23] Internet-Draft Ext. Proxy Services FW July 2000 These trust relationships govern the communication channels between entities, not necessarily the objects upon which the entities are allowed to operate. 7.1.1 AAA in the Existing Web System Model In the traditional client/server Web model, only T2 (end-to-end) and T1/T3 (hop by hop) are present. For T2, HTTP 1.1 [4] contains the WWW-Authenticate header for a server to indicate to the client what authentication scheme to use and the Authorization header for the client to present credentials to a server. The client presents these credentials if it receives a 401 (Unauthorized) response. In RFC 2617, HTTP authentication mechanisms that do not involve clear text transmittal of a password are detailed [5]. At the user level, the mechanism used by the server to authorize and authenticate a client is challenge/response (CHAP) with some kind of login box, but there is no requirement for AAA in general. Access control lists (ACLs) have been proposed as a way to fine tune control [3], so the server could deny a client access to a particular object. In addition, if the server uses TLS (SSL) [1], the client is assured of privacy in its transactions and can send a clear text password. In the other direction, there is no support for a client to authenticate a server. Since the client must discover the server's URL somehow, authentication of the source of the URL can provide some assurance that the URL is trusted. Typically, a person obtains the URL through some non-computational means and the client initiates the connection, so the client must know through some non-computational means that the URL is trusted. Examples of where a client can obtain a URL are through an email message from a friend or co-worker, from a print or TV advertisement, or as a link from another Web page. However, unless the client is running secure DNS [2], the client can't determine whether the server's DNS entry has been hijacked (and such cases have occurred). If TLS [1] is used, then bi-directional authentication is possible. However, TLS primarily performs encryption, which might be unnecessary for a particular application, and, additionally, requires a different URL scheme (HTTPS instead of HTTP). The addition of a proxy without a service environment (except perhaps for caching) changes the trust model to split T2 into T1 and T3 (although this does not mean that T2 is equivalent to T1 and T3). To the server, the proxy acts as a client, while to the client, it acts as the server. HTTP 1.1 contains a header, Proxy-Authenticate, that the proxy sends back to the Tomlinson, et. al. Expires January 11, 2001 [Page 24] Internet-Draft Ext. Proxy Services FW July 2000 client along with a 407 (Proxy Authentication Required) if the client must authenticate itself with the proxy. The client then sends back the Proxy-Authorization header with credentials. This addresses the T1 relationship in the client to proxy direction. The T3 relationship in the proxy to server direction is addressed by having the server respond with a 407 (Proxy Authentication Required) and the Proxy-Authenticate header. Since Proxy-Authenticate is a hop-by-hop header, it can be used to authenticate the proxy to server connection just as it is used for the client to proxy connection. But there is still a lack of authorization and authentication in the proxy to client and server to proxy direction, just as for end-to-end security. For a proxy acting as an avatar, the client is likely to have obtained the URL from a system administrator or other trusted source. Similarly, for a proxy acting as a surrogate, the publishing server typically has a business relationship with the surrogate provider, and the surrogate's URL or address is obtained by the server through some undefined, but necessarily secure means, because the surrogate provider wants to charge the publisher and prohibit unauthorized discovery. 7.1.2 Service Environment Caching Proxy AAA Requirements The lack of a mechanism whereby a client can authorize a proxy and a proxy can authorize a server means that the reverse directions of T1 and T3 are not addressed by HTTP/1.1. In the service environment caching proxy architecture, servers provide the caching proxy with computational objects (rule modules and proxylets) and therefore must be authorized to do so. This generates the first set of AAA requirement for the extensible proxy services architecture: o A mechanism MUST be provided whereby a service environment caching proxy acting as a surrogate can demand authentication information from a server and a server can respond with authentication information appropriate to the request, to authorize the server to provide computational objects. o A mechanism MUST be provided whereby a service environment caching proxy acting as a surrogate can authenticate individual proxylets and rule modules provided by an authorized server, if necessary. Note that authentication of individual objects may not necessarily require a protocol exchange between the proxy and the server, it may be achieved by language Tomlinson, et. al. Expires January 11, 2001 [Page 25] Internet-Draft Ext. Proxy Services FW July 2000 environment-specific mechanisms for performance reasons [6], though a protocol exchange may be desirable for generality. For T1, the existing HTTP Proxy-Authenticate mechanism allows the service environment caching proxy acting as an avatar to authorize the client, but there is no mechanism for authentication of individual proxylets and rule modules, generating the requirement: o A mechanism MUST be provided whereby a service environment caching proxy acting as an avatar can authenticate individual proxylets and rule modules provided by an authorized client, if necessary. The proxy to client direction of T1 requires authentication, even though none is supplied in standard HTTP/1.1. Because a client will be providing computational objects to an avatar, it is essential that the client knows it can trust a service environment caching proxy acting as an avatar; otherwise, the computational objects may be provided to an unauthorized or hostile proxy, much to the client's detriment. This generates a requirement on the proxy to client direction of T1: o A mechanism MUST be provided whereby a client can authenticate a service environment caching proxy offering to act as an avatar. While the discussion above assumes that existing HTTP authentication can be used to authorize T1 in the client to proxy direction and T3 in the proxy to server direction, it may be useful to supplement these methods with additional authentication procedures that are uniform with new procedures introduced in the opposite direction, or provide the new procedures so that they are compatible with the old: o New authentication mechanisms for relationships T1 in the client to proxy direction and T3 in the proxy to server direction SHOULD be uniform with mechanisms in the opposite direction, either by implementing the new mechanisms in a manner similar to the old or by supplementing the old mechanisms with new. This ensures a compatible, easier to use framework for authentication in both directions on the T1 and T3 relationships. Finally, services run on the service environment caching proxy need to be paid. This generates the requirement. Tomlinson, et. al. Expires January 11, 2001 [Page 26] Internet-Draft Ext. Proxy Services FW July 2000 o The service environment caching proxy server MUST be able to deliver secure, nonrepudiable accounting information to a billing entity. 7.1.3 Remote Callout Server AAA Requirements In addition to the injection of proxylet functionality on the caching proxy, the caching proxy can also make use of a remote callout engine to modify particular objects. This architectural piece gives rise to the trust relationship T4, between the caching proxy and the remote callout engine, T5, between the remote callout engine and the server, and T6, between the client and the remote callout engine. Existing remote callout protocols leverage off of HTTP authentication for the remote callout server. The ICAP specification [7] explicitly states that an ICAP server acts as a proxy for purposes of authentication so a proxy client can send any Proxy-Authenticate and Proxy-Authorization headers, although other hop-by-hop headers are not forwarded. However, this has little use for purposes of authenticating trust relationships T7 and T5. The remote callout server may require that the client or publishing server authenticate separately from the proxy, if the remote callout server is owned and administered by a separate entity from the proxy. In addition, a message from the caching proxy to a server that generates a 407 (Proxy Authentication Required) may or may not have been processed by the ICAP server, but in any event, the server won't know that the message was so processed. The server responds to the sender of the message, namely the caching proxy. The caching proxy must respond with its credentials, the ICAP server is essentially invisible as far as the server is concerned. Trust relationships T7 and T5 could derive transitively from T1/T4 and T3/T4. In that case, authorization granted by/to the caching proxy is considered to be authorization granted by/to the remote callout server. If the remote callout server is in the same administrative domain as the caching proxy, as is assumed in the ICAP specification [7], this is likely to be the case. However, in the general case, where the remote callout server resides outside the domain of the service environment caching proxy, authorization by/of the caching proxy server is insufficient. This generates the requirement: o A mechanism MUST be provided whereby, when the remote callout server is outside the administrative domain of the Tomlinson, et. al. Expires January 11, 2001 [Page 27] Internet-Draft Ext. Proxy Services FW July 2000 caching proxy, the remote callout server can directly authenticate with the publishing server and/or with the client, and the client or publishing server can directly authorize a remote callout server independent of the proxy. This requirement, if imposed on the HTTP stream between the client and server, would remove the invisibility of the remote callout server. However, this requirement could be met by an out-of-band authentication procedure, for example, using Diameter [8], in which case the remote callout server would remain invisible during HTTP transactions. ACLs could be established on the server allowing or denying access to the particular data objects for the remote callout server, at the expense of making the remote callout server visible to HTTP streams. Note that there is no need to authenticate computational objects because the remote callout server, by definition, does not receive computational objects from the client and/or publishing server. The trust relationship T4 is on the remote callout to proxy connection. If the remote callout server is in a separate domain, authentication is required between the remote callout server and the caching proxy. Again, proxy authentication can be used in the remote callout to proxy direction, but there is no way for the caching proxy to authenticate the remote callout server. This leads to the requirement: o When the remote callout server is outside the administrative domain of the caching proxy, some means of authenticating the remote callout server with the caching proxy is required. We also require uniform mechanisms on both the forward and reverse directions of T4, and T7 and T5 as well: o The new authentication mechanism for the relationship T4 in the proxy to remote callout direction SHOULD be uniform with the mechanism in the opposite direction, either by implementing the new mechanisms in a manner similar to the old or by supplementing the old mechanisms with new. o Authentication mechanisms for T7 and T5 MAY be uniform with other authentication mechanisms. The requirement on T7 and T5 is looser in order to avoid overly constraining the mechanisms for verifying the other trust relationships, in which backward compatibility considerations may play a large role. Tomlinson, et. al. Expires January 11, 2001 [Page 28] Internet-Draft Ext. Proxy Services FW July 2000 Finally, services run on the remote callout server need to be paid. This generates the requirement. o The remote callout server MUST be able to deliver secure, nonrepudiable accounting information to a billing entity. Most likely, the billing entity will be the administrative server, but it may be another. If the billing entity is the administrative server, and the remote callout server is outside the domain of the caching proxy, the method whereby the accounting information is delivered must be secure and allow nonrepudiation, so that the owners of the remote callout server can be assured of proper billing and payment. 7.1.4 Administrative Server AAA Requirements The administrative server is responsible for injecting proxylets into the service environment caching proxy, and for collecting accounting information from the service environment caching proxy and, transitively, from the remote callout server. The proxylets injected by the administrative server may run at an additional level of trust from those introduced by clients and publishing servers, since they may be involved in collecting accounting information or in other sensitive tasks. From a practical standpoint, the administrative server is highly likely to be within the same administrative domain as the caching proxy, but as with the remote callout server, the case where it is not may also occur. This requires that trust relationship T6 be verified. Therefore, we have the following requirement: o A mechanism MUST be provided whereby, when the administrative server is outside the domain of the caching proxy, mutual authentication between the caching proxy and administrative server is possible. The administrative server also requires some means of obtaining accounting information from the caching proxy and remote callout server: o The administrative server MUST obtain accounting information that is secure and nonrepudiable from the caching proxy and remote callout server. Finally, if the administrative server is allowed to inject proxylets at an additional trust level, an additional authentication mechanism may be required: Tomlinson, et. al. Expires January 11, 2001 [Page 29] Internet-Draft Ext. Proxy Services FW July 2000 o If the administrative server can inject proxylets at a higher trust level into the service environment proxy, a mechanism MUST be provided whereby the additional trust level can be verified (possibly with human involvement). 7.2 Requirements on the Service Execution Environment Although only one client and server are illustrated connected to the caching proxy in Figure 1, the caching proxy may be offering services to multiple upstream and/or downstream peers, some of which may be from mutually exclusive administrative domains. In order to ensure that all parties involved in using a service environment caching proxy are protected, the execution environment must enforce exclusion between separately authenticated and authorized parties. Otherwise, unintentional or malicious interference could occur between rule bases and proxylets running on behalf of separately authorized parties. An analogous situation exists in operating systems on time share machines where multiple, separately authorized parties share a single global execution environment at the operating system level. This goal imposes several requirements on the service execution environment: o A service environment caching proxy MUST ensure that, for a rulebase module associated with a single authorized party, rules are only applied to protocol streams to/from that party. o A service environment caching proxy MUST ensure that a proxylet authorized to run on behalf of one party not be run on behalf of another party that is not authorized to run the proxylet. o A service environment caching proxy MUST prevent any proxylet running on behalf of an authorized party from inspecting or modifying data or code from another, separately authorized party. As with any software system, proxylet libraries are likely to undergo evolution with time. Consistent processing results are likely only if a single version of the library is used to process a message. This generates a requirement on library versions: o A service environment caching proxy MUST ensure that only one version of a given proxylet library is used to process any single message. Tomlinson, et. al. Expires January 11, 2001 [Page 30] Internet-Draft Ext. Proxy Services FW July 2000 Finally, the service environment caching proxy and administrative server may install proxylets for performing various system services, like collection of accounting data. These system services may have access to certain API functions that are not accessible to general proxylets from other clients. This results an additional requirement: o If a service environment caching proxy supports privileged access for authorized proxylets at a higher level of trust, the execution environment MUST exclude unprivileged proxylets from accessing privileged APIs. The inclusion of an API for privileged proxylets in the execution environment MAY generate a requirement for servers downloading privileged proxylets to perform additional authentication (possibly including human involvement), as discussed in the previous subsection. Tomlinson, et. al. Expires January 11, 2001 [Page 31] Internet-Draft Ext. Proxy Services FW July 2000 8. Impact on the Internet Architecture On the face of it, the architecture proposed in this paper for adding services to caching proxies in the Web looks like a major change in the end-to-end model that has been so successful in the Internet. The best solution in terms of preserving the highly successful end-to-end model is to explicitly expose service environment caching proxies by requiring the client or server to discover and authenticate themselves with the proxy. Previous sections have discussed requirements that modify current Web discovery and authentication practices to support varying degrees of exposing service environment caching proxies. It is possible, however, that for business or technical reasons, the provider of proxy services may want to keep the proxy transparent to the client or server (via an interception proxy configuration) during standard day to day operations. The rest of this section discusses transparent service environment proxies in the context of the Internet architecture. The value of the end to end model is that the network is simple and transparent, so it is easy to add services, and easy to diagnose problems when they occur. With the end to end model, there are only two active entities that count, the client and the server (or requesting peer and replying peer in peer-to-peer services). Other entities perform a strictly limited set of functions associated with packet forwarding. Yet, there are a few other cases in which the end-to-end model has been modified. Firewalls and spam filtering on SMTP relays are examples. Both cases are a result of perceived need for control over the content of packet flow, as opposed to simply controlling the flow without regard to content. In the case of firewalls, ISPs and corporate networks require the ability to restrict entry into their co-operatively managed networks, so that only paying customers (for ISPs) or authorized users (for corporations) can gain access to their networks. Firewalls in essence allow the owners of these networks to enforce their property rights with regard to networks that they own. But they also perform another important function: they allow corporations and ISPs to enforce the orderly provisioning of service to users, thereby ensuring the orderly functioning of the Internet at large. Despite the continued controversy over the reduction in transparency caused by firewalls, by and large, firewalls have been successful in performing their function. Proxy DOS attacks and other large scale proxy disruptions of the Internet are impossible to mount from outside through a firewall, and a firewall allows a co-operatively managed Tomlinson, et. al. Expires January 11, 2001 [Page 32] Internet-Draft Ext. Proxy Services FW July 2000 network to disconnect from the Internet for a time, if a major disruption does occur, thereby allowing the network provider to continue providing local service to users. Spam filtering has been less controversial perhaps because the connection to direct user need (and direct daily experience of Internet users) has been more obvious. The nature of email makes it possible for an email sender bent on a disruptive, commercial, or other intent, that may not correspond with the desire of the recipient, to address thousand or millions of recipients, whether or not those recipients want to be addressed by that sender. Spam filtering allows the administrator of an SMTP relay to save his or her users the trouble of having to hand filter tens or hundreds of annoying messages a day. For anybody whose job involves having to deal with hundreds of legitimate messages a day, such a service is invaluable. Both of these examples involve security. Adding the ability of ISPs and other network operators or service providers to insert services into HTTP proxies is a generalization of existing cases away from simple security functions, but it is likewise being driven by the needs of ISPs and other network operators, and by the desires of their users. ISPs and other network service providers want the ability to add services to HTTP proxies because they want to be able to generate additional revenue from added value that they can provide. This added revenue helps assure their viability as commercial concerns, which allows them to continue to provide service to their customers and grow their network offering. Since a viable ISP business is absolutely crucial for the growth and continued maintenance of the Internet, value added services is a way to help augment funding for Internet growth and maintenance. Users benefit from value added services because, like spam filtering, some services may prove invaluable to them. While these services could potentially be provided by adhering to the traditional end to end model, the barrier to deploying such services on clients is large, and growing larger as the number of Internet users grows. Today, many Internet users are consumers that access the Internet through standardized clients that they would just as soon treat as appliances. They would rather not have to upgrade their client software to access new Internet services, due to the potential for disruption in the stability of their daily Internet access environment. In the future, with the advent of true Internet appliances (wireless and otherwise), it may become impossible Tomlinson, et. al. Expires January 11, 2001 [Page 33] Internet-Draft Ext. Proxy Services FW July 2000 to upgrade such clients without throwing the hardware away, and the amount of processing power available in such devices may be unsuitable for performing certain services (such as virus filtering) that proxy value added services can provide. The ability to deploy services on HTTP proxies allows the user's ISP or other network service provider to quickly deploy services that would take years to deploy on clients, and may not even be possible on some low performance clients. If the caching proxy continues to remain largely transparent as a interception proxy, the possibility for abuse is high. Therefore, setting up a value added caching proxy without a business (or other social) relationship between either the client or the server (or both), is a highly unethical act. Clients and servers are encouraged to use authentication to limit their vulnerability to unauthorized intermediate processing on caching proxy. Value added providers are encouraged to advertise the presence of value added services, so that clients know that their Web streams are being modified. Value added caching proxies have a potential to reduce the processing transparency of the Web, but their commercial potential, and thus the value they provide both to publishers and clients, is still higher. In the place of processing transparency, the business and social relationships between clients, caching proxies, and servers should become as non-invasive as possible, so all parties in a Web transaction know the services for which they've contracted and which are being performed by their service providers. Tomlinson, et. al. Expires January 11, 2001 [Page 34] Internet-Draft Ext. Proxy Services FW July 2000 9. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this memo or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Tomlinson, et. al. Expires January 11, 2001 [Page 35] Internet-Draft Ext. Proxy Services FW July 2000 10. Acknowledgements In addition to the authors, valuable discussion instrumental in creating this document has come from Geoff Baehr, of Sun Microsystems; Steven Reynolds, of Enron; Rob Adams, of CMGIon; Steve Holbrook, of Novell; and Ed Haslam, of Inktomi. Tomlinson, et. al. Expires January 11, 2001 [Page 36] Internet-Draft Ext. Proxy Services FW July 2000 References [1] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, January 1999, . [2] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997, . [3] Sedlar, E. and G. Clemm, "Access Control Extensions to WebDAV", Internet-Draft draft-ietf-webdav-acl-01.txt, work in progress, May 2000, . [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] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999, . [6] Oaks, S., "Java Security", May 1998. [7] Elson, J., Martin, J., Sharp, E., Schuster, J., Cerpa, A., Danzig, P., Neerdaels, C. and G. Tomlinson, "ICAP, the Internet Content Adaptation Protocol", External Reference http://www.i-cap.org/icap_v1-25.txt, work in progress, January 2000, . [8] Calhoun, P., Rubens, A., Akhtar, H. and E. Guttman, "DIAMETER Base Protocol", Internet-Draft draft-calhoun-diameter-15.txt, work in progress, June 2000, . [9] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", Internet-Draft draft-ietf-wrec-taxonomy-04.txt, work in progress, June 2000, . Tomlinson, et. al. Expires January 11, 2001 [Page 37] Internet-Draft Ext. Proxy Services FW July 2000 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . [11] FOLDOC, "Free Online Dictionary of Computing: Replication Levels", March 1997, . [12] Volbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Framework", Internet-Draft draft-ietf-aaa-authz-arch-00.txt, work in progress, October 1999, . [13] Stevens, M., Weiss, W., Mahon, H., Moore, B., Strassner, J., Waters, G., Westerinen, A. and J. Wheeler, "Policy Frameworks", Internet-Draft draft-ietf-policy-framework-00.txt, work in progress, September 1999, . [14] Carpenter, B., "Architecture Principles of the Internet", RFC 1958, June 1996, . [15] Carpenter, B., "Internet Transparency", RFC 2775, February 2000, . [16] Cerpa, A., Elson, J., Beheshti, H., Chankhunthod, A., Danzig, P., Jalan, R., Neerdaels, C., Schroeder, T. and G. Tomlinson, "NECP the Network Element Control Protocol", Internet-Draft draft-cerpa-necp-02.txt, work in progress, February 2000, . [17] Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "Web Proxy Auto-Discovery Protocol", Internet-Draft draft-ietf-wrec-wpad-01.txt, expired work in progress, July 1999, . [18] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June Tomlinson, et. al. Expires January 11, 2001 [Page 38] Internet-Draft Ext. Proxy Services FW July 2000 1999, . [19] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems", internet-draft draft-ietf-wrec-known-prob-01.txt, July 2000, . Authors' Addresses Gary Tomlinson Novell, Inc. 1800 South Novell Place Provo, UT 84606-6194 US Phone: +1 801 861 7021 EMail: garyt@novell.com Hilarie Orman Novell, Inc. 1800 South Novell Place Provo, UT 84606-6194 US Phone: +1 801 861 5278 EMail: horman@novell.com Michael Condry Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303-4900 US Phone: +1 650 786 5568 EMail: michael.condry@sun.com James Kempf Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303-4900 US Phone: +1 650 786 5890 EMail: james.kempf@sun.com Tomlinson, et. al. Expires January 11, 2001 [Page 39] Internet-Draft Ext. Proxy Services FW July 2000 Dave Farber Digital Island 225 West Hillcrest Drive, Suite 250 Thousand Oaks, CA 91360 US Phone: +1 805 370 2190 EMail: dave@digisle.net Tomlinson, et. al. Expires January 11, 2001 [Page 40] Internet-Draft Ext. Proxy Services FW July 2000 Appendix A. Examples The following applications illustrate particular features of the service environment proxy architecture and how the architecture can be used to implement some services that would be difficult to implement in other ways. A.1 Request Identification A simple problem is how to attach a custom identification, such as a cookie or serial number, to a particular type of request. The service definition consists of a rule that matches an identifying field in the message header, like the origin address. When the rule triggers, a proxylet generates the identification, perhaps by querying the content server, and adds it by attaching another header field. The request identification rule is triggered at execution point 2 in Figure 1, since the identification is made on an incoming request, and it is only made if the request is not fulfilled from the cache. Request identification could be handled directly by the content server, but addition of the service environment proxy allows multiple content servers potentially from multiple administrative domains to subscribe to the same request identification service without having to separately implement the service, and to potentially correlate identifications. A.2 Content Assembly A common use of proxies today is to insert advertisements into Web pages. Surrogates are commonly used in the Internet to perform customized ad generation on Web pages. This application can be generalized to content assembly of any kind from multiple origin servers. Content assembly illustrates the need for message parsers that handle the contents of messages as well as the headers. In order to determine whether and where content must be inserted, a marker is required within the content. For example, a tag such as "" in the content may indicate where the advertisement should be inserted. The tag may contain information indicating where to obtain the ad or the location of the ad content be determined computationally when the ad is inserted. The rule engine must respond to method properties derived from content as well as headers, and the content must be made available to the proxylet in a way that allows the proxylet to reassemble the Web page with the new content inserted. In order to avoid serious performance penalties, parsing of the message should be performed only Tomlinson, et. al. Expires January 11, 2001 [Page 41] Internet-Draft Ext. Proxy Services FW July 2000 once. Content assembly runs at execution point 3 (for cached responses) or execution point 4 (for personalized responses) as defined in Figure 1. A.3 Multimedia Stream Management This example illustrates how a service environment caching proxy can provide a different caching algorithm than LRU for content that has different requirements. Multimedia content is a growing part of Web traffic, but the caching strategy used with multimedia may need to be different because the streams are real time and the amount of date involved is larger than standard text and graphics Web pages. A proxylet can be used to manage the cache for more effective caching of multimedia data. An example where such a caching policy might be required is showing movies on demand to multiple clients from one incoming stream. The incoming stream is maintained in the cache for some period of time, and new users who request movie content within that time window have their requests fulfilled from the cache rather than directly from the origin server. The cache copy is periodically refreshed as the time window expires, at which point, the proxy must go back to the origin server if another request for the movie comes in. The cache provides multiple client streams and does accounting for clients watching movie. If the protocol used to transport the movie is RTSP, the packet headers need to be transformed as they are removed from the cache for delivery so each client receives an appropriate header. This occurs at execution point 4 in Figure 1, since the changes are made after the packets are removed from the cache for delivery back to the client. A.4 Virus Detection An example of an application that would benefit from having a remote callout server is virus detection. Because virus detection might be computationally expensive, the service execution environment should have the option of calling on more powerful computational resources. In addition, a customer could outsource virus detection to a computer security firm that specializes in tracking viruses and provides fast detection solutions. By allowing a remote callout server to perform the detection, the customer achieves the benefit of specialized help for their security needs. Virus detection would typically run on an avatar, but it might also run on a surrogate that is taking uploaded material from user agents. Tomlinson, et. al. Expires January 11, 2001 [Page 42] Internet-Draft Ext. Proxy Services FW July 2000 In the virus detection example, the message parser and rule engine detect data objects that could potentially contain viruses, and vector off to the remote callout server to verify the data objects. Virus scanning typically runs at execution point 3 in an avatar and execution point 1 in a surrogate, to prevent virus-infected material from being cached. A.5 Transcoding This example illustrates an application for service environment proxies that would be difficult to implement in any other way. Wireless devices often have screen, keyboard, and network bandwidth constraints that don't apply to other devices. The current way of accommodating those constraints is to construct a gateway that short-circuits requests and fulfills them with customized content that matches the constraints of the device, potentially even over a different networking protocol (i.e. WAP). With a service environment proxy, the rule base can identify requests from devices that have some kind of user interface or network bandwidth constraint, and trigger a proxylet that processes the content to transcode it into a format that is more appropriate for the device. The advantage of the service environment proxy solution is that the content need be written only once, while gateways require that multiple copies of the content to be available matching different device characteristics. Transcoding can also be used for other purposes, for example, to translate a Web page into multiple languages. Tomlinson, et. al. Expires January 11, 2001 [Page 43] Internet-Draft Ext. Proxy Services FW July 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). 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 11, 2001 [Page 44]