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,
<http://www.rfc-editor.org/rfc/rfc2246.txt>.
[2] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997,
<http://www.rfc-editor.org/rfc/rfc2065.txt>.
[3] Sedlar, E. and G. Clemm, "Access Control Extensions to
WebDAV", Internet-Draft draft-ietf-webdav-acl-01.txt,
work in progress, May 2000,
<http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-01.txt>
.
[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,
<http://www.rfc-editor.org/rfc/rfc2616.txt>.
[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,
<http://www.rfc-editor.org/rfc/rfc2617.txt>.
[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,
<http://www.i-cap.org/icap_v1-25.txt>.
[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,
<http://www.ietf.org/internet-drafts/draft-calhoun-diameter-15.txt>
.
[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,
<http://www.ietf.org/internet-drafts/draft-ietf-wrec-taxonomy-04.txt>
.
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,
<http://www.rfc-editor.org/rfc/rfc2119.txt>.
[11] FOLDOC, "Free Online Dictionary of Computing:
Replication Levels", March 1997,
<http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=service>
.
[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,
<http://www.ietf.org/internet-drafts/draft-ietf-aaa-authz-arch-00.txt>
.
[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,
<http://www.ietf.org/internet-drafts/draft-ietf-policy-framework-00.txt>
.
[14] Carpenter, B., "Architecture Principles of the
Internet", RFC 1958, June 1996,
<http://www.rfc-editor.org/rfc/rfc1958.txt>.
[15] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000,
<http://www.rfc-editor.org/rfc/rfc2775.txt>.
[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,
<http://www.ietf.org/internet-drafts/draft-cerpa-necp-02.txt>
.
[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,
<http://www.wrec.org/Drafts/draft-ietf-wrec-wpad-01.txt>.
[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, <http://www.rfc-editor.org/rfc/rfc2608.txt>.
[19] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching
Problems", internet-draft
draft-ietf-wrec-known-prob-01.txt, July 2000,
<http://www.ietf.org/internet-drafts/draft-ietf-wrec-known-prob-01.txt>
.
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 "<your ad here>" 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]