Network Working Group G. Tomlinson
Internet-Draft CacheFlow
Expires: May 20, 2002 R. Chen
AT&T
M. Hofmann
Lucent
R. Penno
A. Barbir
Nortel Networks
November 20, 2001
A Model for Open Pluggable Edge Services
draft-tomlinson-opes-model-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 20, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Intellectual Property Existence
The authors are aware of the existence of intellectual property
associated with certain specific edge service implementations of
the high level-model described herein.
Editor Note: Companies must submit Intellectual property statements
to the IETF using regular procedures.
Tomlinson, et. al. Expires May 20, 2002 [Page 1]
Internet-Draft OPES Model November 2001
Abstract
Content Delivery plays an important role in the overall
architecture of the web. Content providers and content consumers
are increasingly looking for additional services beyond basic
content delivery. In particular, content providers are interested
in providing value-add services that can be performed on the content.
This document provides a model for Open Pluggable Edge Services
(OPES), an infrastructure for adding value added service to content.
The elements of a common vocabulary that defines the infrastructure
of edge services are also introduced.
Table of Content
1. Introduction ............................................... 3
2. OPES Model Terms ........................................... 4
3. Overlay Networks ........................................... 9
3.1 Packet Networks ............................................ 9
3.2 Content Networks Overlay ...................................11
3.3 Content Service Networks ...................................12
3.3.1 OPES: Content Service Networks .............................14
4. OPES System Relationships ..................................14
4.1 Core Component Relationships ...............................15
4.1.1 Deployment Scenarios Supported by this Model ...............16
4.1.2 OPES Intermediary ..........................................17
4.1.2.1 OPES Engine ................................................18
4.1.2.2 Local Execution Environment: The Proxylet Run-time System ..19
4.1.2.3 Remote Execution Environment: The Remote Call-out System ..19
4.2 Remote Call-out Servers ....................................20
4.3 OPES Admin Server ..........................................20
4.3.1 Authentication Services ....................................20
4.3.2 Authorization (Policy) Services ............................21
4.3.3 Accounting Services ........................................21
4.4 Surrogate Overlays .........................................21
4.5 Delegate Overlays ..........................................23
5. End-to-End Data Integrity ..................................24
5.1 Requirements for End-to-End Data Integrity .................24
5.1.1 One-party consent ..........................................24
5.1.2 IP-layer communications ....................................25
5.1.3 Notification ...............................................25
5.1.4 Non-blocking ...............................................25
5.1.5 Privacy ....................................................25
6. Security Considerations ....................................26
6.1 Threats to the underlying Content Network ..................27
6.2 Threats to the OPES Edge Services Network ..................27
6.3 Threats to the Local Execution Environment .................27
6.4 Threats to the Remote Execution Environment ................28
7. Acknowledgements ...........................................28
References .................................................28
Tomlinson, et. al. Expires May 20, 2002 [Page 2]
Internet-Draft OPES Model November 2001
1. Introduction
Content Delivery is of increasing importance to the overall
Architecture of the web. Content providers and content
consumers are increasingly looking for enhanced services
beyond basic content delivery. In particular, they are interested
in providing value-add services that operate on content on its way
between the content origin and content consumer. Such services are
termed "Content Services". Examples of content services include:
dynamic content assembly, content personalization, virus scanning,
and content adaptation for different device types [11].
While some such services are already being offered by web servers
or by client software, there are good reasons to develop an overlay
infrastructure that support the provisioning of content services
in a distributed manner. We will refer to such an infrastructure
as Content Service Network (note that Edge Service Network has also
been used in previous documents).
The development of content service networks addresses some of the
problems that current providers of content services are facing. In
particular, providing content services only at a central web server,
for example, entails the well-known risk of server overload,
increased network load, high service latency and availability.
On the other hand, providing content services only at the client
might not always be an option, since some user agents like Personal
Digital Assistants (PDA) and mobile phones may not have the
processing power required to run the software for providing such
services. Furthermore, most Internet users want to take advantage
of content services without having to worry about technical matters
like software installations or updates. Besides, some Internet
appliances may only be capable of running hard coded software so
that software upgrades would not be possible at all.
In other words, this is a problem of intelligence, where
intelligence in the network will reside. In theory we could put all
kinds of features in routers or end clients, but this doesn't scale.
On the other hand, content service networks are layered onto an
underlying network, in most cases an IP network, and offer content
services that provide a value-add to the content being delivered.
Content service networks provide services that operate on messages
that are passing through the underlying network.
The introduction of content service networks requires the
development of mechanisms that guarantee the integrity of the
content in transit in the Internet between client/intermediary,
intermediary/intermediary, and intermediary/origin server. The
introduction of content service networks must not violate and must
protect the end-to-end data model of the Internet as described by
the IAB in [18].
Tomlinson, et. al. Expires May 20, 2002 [Page 3]
Internet-Draft OPES Model November 2001
The document presents a vocabulary for use in developing content
service networks and describes the core components of such, and
their relationships. Section 2 introduces the terms used for
elements of an content service network and explains how those terms
are used. Section 3 explains the concept of overlay networks and how
different types of such are built upon each other. The core OPES
components and their relationship are introduced in Section 4. In
Section 5, the requirements for end-to-end data integrity are
discussed, while security considerations are discussed in Section 6.
2. OPES Model Terms
The section provides the definitions of a number of terms used
to refer to the roles, participants, and objects involved in OPES
service overlay networks. Although the following uses many terms
used in RFC 2616 [4] and RFC 3040 [6], there is no required
dependency on HTTP or web caching technology. This vocabulary is
applicable to other protocols and content networks. Words enveloped
within 'single quotes' are defined terms within this document.
ACTION
An action is a form of a policy action[10] that results in the
execution of an 'OPES service module' when 'conditions' of a
'rule' are met.
AUTHORITATIVE DOMAIN
A logical domain in which the network elements have rights,
either delegated or inherited to act authoritatively on behalf of
a party. This logical domain may be wholly contained within the
administrative domain [2] of the party, or it may be a collection
of administrative domains in which the party rights have been
delegated.
AVATAR
Deprecated, see 'delegate'.
CACHE (reference definition [4])
A program's local store of response messages and the subsystem
that controls its message storage, retrieval, and deletion. A
cache stores cacheable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent
requests. Any client or server may include a cache, though a
cache cannot be used by a server that is acting as a tunnel.
CACHING PROXY (reference definition [6])
A proxy with a cache, acting as a server to clients, and a client
to servers. Caching proxies are often referred to as "proxy
caches" or simply "caches". The term "proxy" is also frequently
misused when referring to caching proxies.
Tomlinson, et. al. Expires May 20, 2002 [Page 4]
Internet-Draft OPES Model November 2001
CLIENT (reference definition [4])
A program that establishes connections for the purpose of sending
requests.
CONDITION
A form of a policy condition [10] that is an expression which is
used to determine whether a 'rule' 'action' should be executed.
CONFIGURATION PATH
'Rule modules' and 'OPES service modules' are downloaded into an
'OPES admin server' from 'rule authors' and 'proxylet
providers', respectively, and then distributed to the 'OPES
intermediary'. This flow is referred to as the configuration
path, since the data being transferred along this path is used to
provision the 'OPES intermediaries' for service.
CONTENT CONSUMER
The 'client' that is the final destination of content delivery.
CONTENT PATH
The content path describes the path that content requests and
responses take through the network. Typically, content requests
and responses flow between a client, an 'OPES intermediary', and
a 'content server'.
CONTENT SERVER
The server on which content is delivered from. It may be an
'origin server', replica server, 'surrogate' or parent proxy.
CONTENT SERVICE
A service operating on and providing a value-add to content.
CONTENT SERVICE NETWORK
An overlay network of 'intermediaries' layered onto an underlying
network that incorporate 'content services' that
operate on messages flowing through the 'content path'.
DELEGATE
A 'caching proxy' located near or at the network access point of
the 'user agent', delegated the authority to operate on behalf
of, and typically working in close co-operation with a group of
'user agents'.
Tomlinson, et. al. Expires May 20, 2002 [Page 5]
Internet-Draft OPES Model November 2001
In-PATH
In-Path Content Services are naturally within the message path of
the application they are associated with. This may be an
application proxy, gateway, or in the extreme case, one of the
end-hosts, that is party to the application [14].
INTERMEDIARY
Intermediaries are application gateway devices located in the
'content path' between 'client' and 'origin server'. 'Caching
proxies' and 'surrogates' are probably the most commonly known
and used intermediaries today.
OPES ADMIN SERVER
An OPES admin server performs authentication, authorization and
accounting (AAA) functions for an OPES content services network'.
These function include, but are not limited to downloading of
'proxylets' and 'rule modules' from trusted parties,
authorization and authentication of 'OPES services', the
collection of accounting and log data, and other administrative
tasks. It must be a member of the 'authoritative domain' of the
parties it is authorizing 'content services' It must be a member
of the party's 'authoritative domain' on whose behalf it is
provisioning 'content services'.
OPES DEVICE
Deprecated, see 'OPES intermediary'.
OPES ENGINE
An OPES engine allows new services to be defined and executed on
'OPES intermediaries' according to the policies set up by an
'OPES admin server'. OPES Engine contains a message parser, and a
rule processor that reside in the flow of content passing through
the 'OPES intermediary' collectively form a 'PEP'. The 'OPES
engine' calls actions which reside in either the 'proxylet
run-time system' or as 'remote call-out stubs'.
OPES INTERMEDIARY
An "intermediary" device integrating a compliant 'OPES engine'.
OPES intermediaries are typically hosted on 'delegates' or
'surrogates'.
OPES SERVICE
An OPES service is an authorized 'content service' performed on a
message flowing through the 'content path' by a 'OPES service
module'.
OPES SERVICE MODULE
OPES service modules are executable code modules that are
executed ether on the local 'proxylet run-time system' or on the
'remote call-out server'.
Tomlinson, et. al. Expires May 20, 2002 [Page 6]
Internet-Draft OPES Model November 2001
ORIGIN SERVER (reference definition [4])
The server on which a given resource resides or is to be created.
OUT-OF-PATH
Out-of-Path Content Services are not natively in the transport
path of an application. In other words, they are not necessarily
resident (or co-resident) on entities that are natively in the
path of application flows [15]
OVERLAY NETWORK
A set of connected network elements layered onto existing
underlying networks, and presented as a virtual application layer
to both 'clients' and 'origin servers'.
PDP
See 'policy decision point'.
PEP
See 'policy enforcement point'.
POLICY DECISION POINT (reference definition [10])
A logical entity that makes policy decisions for itself or for
other network elements that request such decisions.
POLICY ENFORCEMENT POINT (reference definition [10])
A logical entity that enforces policy decisions.
PROXYLET
A proxylet is a 'OPES service module' that runs on the 'OPES
intermediary' within the 'proxylet run-time system' and provides
a service on 'content path' requests or responses.
PROXYLET LIBRARY
Proxylet library is a library provided to support runtime
services in the 'proxylet runtime system'.
PROXYLET META-DATA
Proxylet meta-data describes the characteristics, features and
requirements associated with a proxylet. Examples for such meta-
data are the name of the 'proxylet', its functionality, its
version number, where to get it, license related information,
execution environments, etc. The meta-data can physically be
separated from the 'proxylet' code, but it must be possible to
uniquely associate meta-data with 'proxylets' and vice versa.
PROXYLET PROVIDER
Proxylet provider is the party that provides the 'proxylet' 'OPES
service module' to the 'OPES admin server'.
Tomlinson, et. al. Expires May 20, 2002 [Page 7]
Internet-Draft OPES Model November 2001
PROXYLET RUN-TIME SYSTEM
The local execution environment on an 'OPES intermediary'.
'Proxylets' execute as local (as opposed to 'remote call-out')
'actions' within this environment.
REMOTE CALL-OUT
A remote procedure call made via a 'remote call-out protocol" to
a 'remote call-out server' that is invoked as the result of an
'action'.
REMOTE CALL-OUT PROTOCOL
The network protocol that encapsulates and transports a 'remote
call-out' between an 'OPES intermediary' and a 'remote call-out
server'.
REMOTE CALL-OUT STUB
A remote procedure call stub running on the 'OPES intermediary'
that binds a 'remote call-out' to the 'OPES engine' as 'actions'.
The stub marshals the 'action' to/from the 'remote call-out
protocol'.
REMOTE CALL-OUT SERVER
A cooperating server which runs 'OPES service modules' as the
result of a 'remote call-out'.
ROLE (reference definition [10])
An administratively specified characteristic of a managed element
(for example, an interface). It is a selector for policy rules
and 'rule modules', to determine the applicability of the
rule/'rule module' to a particular managed element.
Note: Provisioning Class has been substituted with 'rule module'
in this definition, as 'rule modules' are instances of
Provisioning Classes within the OPES application domain.
RULE
Rules are forms of policy rules [10] that contain 'conditions' and
'actions' that are to be executed if the 'conditions' are met.
RULE AUTHOR
The rule author is the party that authors and provides a 'rule
module' to the 'OPES admin server'.
RULE MODULE
A rule module is a form of a policy Provisioning Class [10] that
contains a set of 'rules' and information about the rule module
owner.
Tomlinson, et. al. Expires May 20, 2002 [Page 8]
Internet-Draft OPES Model November 2001
SURROGATE (reference definition [6])
A gateway co-located with an origin server, or at a different
point in the network, delegated the authority to operate on
behalf of, and typically working in close co-operation with, one
or more origin servers. Responses are typically delivered from an
internal cache.
Surrogates may derive cache entries from the origin server or
from another of the origin server's delegates. In some cases a
surrogate may tunnel such requests.
Where close co-operation between origin servers and surrogates
exists, this enables modifications of some protocol requirements,
including the Cache-Control directives in [4]. Such modifications
have yet to be fully specified.
Devices commonly known as "reverse proxies" and "(origin) server
accelerators" are both more properly defined as surrogates.
TRIGGER
See 'condition'.
USER AGENT [4]
The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user
tools.
3. Overlay Networks
'Content Service networks', of which OPES is a form, rely on
underlying Networks as a platform to provide transport services.
Content service networks utilize the relatively new 'overlay
network' paradigm. Overlay networks are a powerful abstraction
that create a virtual network of connected devices layered on an
existing underlying network in order to present application level
services. Since OPES is based on 'overlay network' architectures,
the discussion will begin with them.
3.1 Packet Networks
We begin with a brief overview of Packet Networks. Packet Networks
are physical networks comprised of routers and other network
elements including link devices. Of particular interest to OPES are
IP [1] based packet networks, including the Internet itself. IP
networks form the base infrastructure onto which 'overlay networks',
including OPES Content Service Networks will be layered.
Tomlinson, et. al. Expires May 20, 2002 [Page 9]
Internet-Draft OPES Model November 2001
+--------+
/ Client /
+--------+
^
/
v
_______________(X)___________________
/ Router /
/ /
+--------+ / IP / +-------+
/ Client /<->(X) Packet Network (X)<->/ Origin /
+--------+ / / / Server /
/ / +--------+
/_________________(X)_________________/
^
/
v
+--------+
/ Client /
+--------+
Figure 1. IP Packet Network
Note: underlying links and internetwork boundaries are
omitted for simplicity.
Figure 1 depicts a diagram of an IP based Packet Network. The
figure represents the classic Internet model. Here, each application
device is connected to the IP packet network via router elements
(X). 'Clients' establish a session with 'servers' and communicate
via packets that are routed transparently [5] through the packet
network. This communication relationship between the 'client' and
'server' is known as the end-to-end [3] model and is a fundamental
principle of the Internet architecture. What this means is, the
packet network doesn't process any application content; it simply
transits it to the end points, where all of the application
intelligence exists.
The end-to-end model has proven to be very successful. However, as
we shall see in subsequent sections, there is a class of
applications, namely the world wide web and streaming media for
which it doesn't perform adequately in an increasing number of
instances.
Tomlinson, et. al. Expires May 20, 2002 [Page 10]
Internet-Draft OPES Model November 2001
3.2 Content Networks Overlay
As the scale and reach of IP packet networks, particularly the
Internet, has grown, a number of applications such as content
delivery, the world wide web and streaming media did not always
scale with the end-to-end model of the Internet. This is due to
network congestion and the cumulative latency of internetworking.
Essentially, network latency can cause unacceptable levels of jitter
and packet loss that reduce the quality of streaming media. It also
adds to the delay times for web applications, often to the point,
that the quality of delivery is unacceptable to recipient.
In order to address the above problems several new technologies such
as Diffserv and MPLS have been proposed. Diffserv and MPLS aim
towards providing some form of QoS or traffic engineering across the
network, such that the quality of delivery of content to the end
user is guaranteed.
Content networks on the other hand consists of using intermediaries
in the network for the delivery of content in a close proximity to
the content consumer. These overlay networks create a virtual
overlay on top of IP packet networks, that via 'intermediaries'
enables the necessary network infrastructure to provide better
content delivery services.
Figure 2 contains a diagram of an Content Network Overlay. In this
model in which content engine 'intermediaries' (e) are added, each
application device continues to be connected to the IP packet
network via router elements (X). The content engines collectively
form a network overlay in which they service requests on behalf of
'origin servers'. In this model, the 'Clients' establish a session
with a content engine (e) in the content path that is located near
them rather than with the 'origin server', and communicate with it
via packets that are routed through the packet network. The content
engine establish sessions with the 'origin server' and act as an
intermediary in the 'content path'. This model retains the end to
end nature, however it introduces application gateways between
independent end-to-end sessions. The 'intermediaries' logically add
intelligence to the network infrastructure in the form of an
'overlay network'.
By placing content engines topologically disperse through out the IP
packet network and in close proximity with 'clients', the
impediments of network congestion and network latency are removed.
This enables web and streaming media applications to deliver content
in a timely and scalable manner.
Tomlinson, et. al. Expires May 20, 2002 [Page 11]
Internet-Draft OPES Model November 2001
Fundamentally there are two forms of content engines, the
'delegate' and the 'surrogate'. 'Delegates', are authorized agents
'intermediaries' that act on behalf of 'clients'. Surrogates on the
other hand, are authorized agent 'intermediaries' that act on behalf
of 'origin servers'. Content engines are strategically placed in the
'content path' and as such are ideal platforms for 'content
services'. We will discuss how they are used as the base
infrastructure upon which content service networks are overlaid in
the next section.
+--------+
/ Client /
+--------+
^
/
v
____________________(e)_________________
/ Content /
/ engine /
+--------+ / /__
/ Client /<->(e) Content Network / /
+--------+ / / /
/ / /
/ / / +-------+
/___________________(e)_________________/ (X)<->/Origin /
/ ^ / / Server/
/ | Packet Network / +-------+
/___________________(X)_________________/
^
/
v
+--------+
/ Client /
+--------+
Figure 2. Content Network Overlay
3.3 Content Service Networks
Content service networks provide services that act on content flowing
through the 'content path'. This value-added processing of the
content is known as 'content services'.
Tomlinson, et. al. Expires May 20, 2002 [Page 12]
Internet-Draft OPES Model November 2001
Content service networks are a specialized form of application
network Overlays. Content service networks are constrained to
provide services only on the 'content path', as opposed to
general applications. Content service networks provide a mechanism
for vectoring the content flow to service modules for processing.
This vectoring is accomplished with a message parser and 'rules'
that set 'conditions' to trap on the content flowing through the
'content path'. This process is a classic example of a policy 'PEP'.
Figure 3 contains a model of Content Services Network Overlay. In the
model 'clients' establish a session with a content engine (e) in the
virtual content layer that is located near them rather than with the
'origin server', and communicate with it via packets that are routed
through the packet network. Messages that 'trigger' a 'condition'
registered by a 'rule author' as a 'content service' (i) are
vectored to the service module (ag) for content processing. The
results are returned from the service module and placed back in the
content flow. The rest of the system behaves like the previous
example Figure 2.
3.3.1 OPES: Content Service Networks
OPES is a form of 'edge (i.e. content) service network'. OPES
utilizes 'surrogates' and 'delegates' as 'OPES intermediaries'
that provide pluggable edge services. OPES also adds additional
network elements to its overlay that include administration and
'remote call-out' processing. Additionally, an OPES content
service network' is constrained to be authorized by the party
for which 'content services' are being performed, either the
'origin server' or the 'content consumer'.
Tomlinson, et. al. Expires May 20, 2002 [Page 13]
Internet-Draft OPES Model November 2001
+--------+
/ Client /
+--------+
^
/
v
_________________(i)___________________
/ intermediary /
/ content services /
+--------+ / /___
/ Client /<->(i) Content Services Network Overlay / /
+--------+ / (ag)/ /
/ (ag) / /___
/___________________(i)_________________/ / /
/ . / /
/ . Content Network / / +-------+
/___________________(e)__________________/ (X)<->/ Origin /
/ ^ / / Server /
/ | Packet Network / +--------+
/___________________(X)___________________/
^
/
v
+--------+
/ Client /
+--------+
Figure 3. Content Services Network Overlay
OPES employs a security trust model for establishing delegated
authority to act on behalf of a principal party. In this security
trust model there is a principal party ('content consumer' or
'origin server'), the party has rights, and the rights can be
delegated to or inherited by the OPES content services network'.
When such effective rights are granted to the OPES ' content
services network' via a negotiated relationship, it is said to
be in the 'authoritative domain'. In [16,17] there are more
detailed discussions of these issues.
4. OPES System Relationships
In this section, we propose an OPES system model that allows us to
examine the core components of an OPES 'content service network'
and the relationships among them in detail.
We also apply this model to two content service overlay networks:
the surrogate overlay network that represents the interests of
content providers and the delegate network that represents the
interests of content consumers.
Tomlinson, et. al. Expires May 20, 2002 [Page 14]
Internet-Draft OPES Model November 2001
4.1 Core Component Relationships
In this section, we propose an OPES system model that allows us to
examine the core components of an OPES 'content service network'
and the relationships among them in detail.
We also apply this model to two content service overlay networks:
the surrogate overlay network that represents the interests of
content providers and the delegate overlay network that represents
the interests of 'content consumers'.
Figure 4 contains a diagram of the network elements involved in the
OPES Content Service System Model. The 'OPES intermediary', an
'intermediary' that hosts the 'OPES Engine', is located on the
'content path' between the 'user agent' and 'content server'. The
device consists of three logical components: the 'OPES engine', the
local execution environment, and the remote execution environment.
The 'OPES engine' provides 'content services' on the requested
content before its delivery by invoking appropriate 'actions' on the
content in one of the two execution environments.
The 'OPES intermediary' also interacts with other logical components
not on the 'content path': the 'OPES admin server' and the 'remote
call-out servers'. The 'OPES admin server' provides authentication
services to identify trusted parties within an OPES 'content services
network', authorization services to determine if a 'content service'
is authorized, and accounting services to log the usage of the 'OPES
intermediary'. The 'OPES admin server' may or may not be
physically located on the same 'OPES intermediary', but they should
belong to the same administrative domain[2]. 'Remote call-out
servers' are invoked through the remote execution environment for
services on messages which are not available locally.
We first give examples of deployment scenarios supported by this
model, then we examine each logical component and the relationships
among the components in detail.
Tomlinson, et. al. Expires May 20, 2002 [Page 15]
Internet-Draft OPES Model November 2001
+-----------------+
| Remote Call-out |
| Server |
+-----------------+
^
|
|
v
+--------------------------+
| +----------+ +---------+ |
| | Local | | Remote | |
| | Exec. | | Exec. | |
| | Env. | | Env. | |
+-------+ | +----------+ +---------+ | +---------+
| User | | +----------------------+ | | Content |
| Agent |<----->| | OPES Engine/PEP | |<----->| Server |
+-------+ | +----------------------+ | +---------+
| OPES |
| Intermediary |
+--------------------------+
^
|
|
v
+-----------------------+
| OPES Admin |
| Server |
| +-------------------+ |
| | Authentication | |
| +-------------------+ |
| | Authorization/PDP | |
| +-------------------+ |
| | Accounting | |
| +-------------------+ |
+-----------------------+
Figure 4. OPES Edge Service System Model Components
4.1.1 Deployment Scenarios Supported by this Model
Our model document attempts to support a wide range of OPES
deployment scenarios, including, but not limited to the following:
Tomlinson, et. al. Expires May 20, 2002 [Page 16]
Internet-Draft OPES Model November 2001
- 'OPES intermediary' is the 'client' device: A 'content
consumer' may decide to install an 'OPES intermediary' on his or
her desktop for personal 'content services'. In this case, the
'OPES intermediary' serves only one user. The 'OPES admin server'
may degenerate to a simple service that denies requests from any
other IP addresses and allows the user full control on the 'rule
modules'.
- 'OPES intermediary' is owned by an enterprise and deployed on the
intranet: In this case, any one who can connect to the 'OPES
intermediary' is already on the intranet. Many OPES services such
as virus checking and URL filtering provided by this box may not
require authentication or authorization of the users at all. On
the other hand, the enterprise owner may elect to reuse the
company's existing administration services to provision 'OPES
services' that require unique user identification to personalize
the services.
- 'OPES intermediary' is owned by a "Middleware Service Provider"
(MSP): In this case, the MSP may not be the access provider, but
it provides middleware services for anyone who registers to
become a user. It provides service provisioning and charges fees
for its services. For example, an ISP user may use middleware
services such as language translation or location-aware services
provided by an MSP even though that MSP does not provide any
internet access services.
- 'OPES intermediary' is owned by an ISP: One or multiple 'OPES
intermediaries' may be deployed in the access provider's network.
ISPs are more likely to be interested in value-added services
that they can resell to their subscribers and in services that
would simplify their general administrative tasks.
- 'OPES intermediary' is owned by a CDN: CDN providers can deploy
'OPES engines' on 'surrogates' that provide CDN services on
behalf of content providers (i.e. the customers of the CDN). CDN
providers are likely to be more interested in services that they
can offer to content providers, in particular to enable secure,
scalable, and profitable distribution of valuable content.
For more detailed discussions on the OPES deployment scenarios, see
[11].
4.1.2 OPES Intermediary
An 'OPES intermediary' should consist of minimally the 'OPES engine'
and a local execution environment for 'actions' that are 'triggered'
by the 'rules'. It may optionally consist of a remote execution
environment for interactions with remote call-out servers. The
'intermediary' may consist of other logical components (such as a
Tomlinson, et. al. Expires May 20, 2002 [Page 17]
Internet-Draft OPES Model November 2001
cache) not described in this document. Figure 5 contains a diagram
of the three core components of an 'OPES intermediary' and their
internal structure. We examine each component in detail in the
following subsections.
Remote Call-out Protocol(s)
^ ^
: :
: :
+------------------------+ v v
| +----------+---------+ | +----------+----------+
| | Proxylet | Proxlet | | | Remote | Remote |
| +----------+---------+ | | Call-out | Call-out |
| | Proxylet Library | | | Stub | Stub |
| +--------------------+ | +----------+----------+
| Proxylet Run-time | | Remote Call-out |
| System | | System |
+------------------------+ +---------------------+
Local Exec. Env. Remote Exec. Env.
+------------------------------------------------+
| +-------------+-------------+ |
| | Rule Module | Rule Module | | C S
A | +---------------------------+ | o e
U g Responses | Rule Processor | Responses n r
s e <============4== +---------------------------+ <=3=========== t v
e n Requests | Message Parser | Requests e e
r t =============1=> +---------------------------+ ==2==========> n r
s | OPES Engine | t
+------------------------------------------------+
Figure. 5 System Model Components
4.1.2.1 OPES Engine
The 'OPES engine' consists of the following logical components: a
message parser, a rule processor, and 'rule modules', which
collectively constitute a 'PEP', policy enforcement point. The
message parser examines the request and response messages. The rule
processor evaluates the parsed results against 'rule modules'
described with a policy language such as the proposed IRML [7].
The 'OPES engine' controls insertion of 'content services' into the
flow via it's 'PEP' and policy 'roles'. There is a 'role' associated
with each of the logical points in the message flow (currently
predefined points 1 thru 4 in Figure 5):
- Point 1: A request is received from the 'user agent'.
Tomlinson, et. al. Expires May 20, 2002 [Page 18]
Internet-Draft OPES Model November 2001
- Point 2: A request is about to be forwarded to the 'origin
server'.
- Point 3: A response has just arrived from the 'origin server'.
- Point 4: A response is about to be delivered to the 'user agent'.
Each 'role' has its associated 'rules' and it relies on the 'PEP' to
determine whether certain 'actions' should be taken. The 'PEP' may
be authorized to make a decision for certain rules, otherwise it
must interact with the 'OPES admin server', which acts as a policy
decision point, 'PDP' to obtain authorization.
[Note: for more information on policy within an OPES 'content
services network' see [12]].
4.1.2.2 Local Execution Environment: The Proxylet Run-time System
The 'proxylet run-time system' provides a local execution
environment or 'actions' that can be performed on the 'OPES
intermediary'. The system consists of intrinsic functions known as
the 'proxylet library' and loadable extensions known as 'proxylets'
that invoke the library functions. Local operations are considered
In-path.
Similar to 'rules', a 'proxylet' is downloaded from a 'proxylet
provider' to an 'OPES admin server'. In addition to the
authentication process, the 'OPES admin server' also performs
proxylet "sandbox" validation to make sure that the 'proxylet'
conforms to local policies (e.g. what resource it is allowed to
access, etc.). Only after successful validation, the 'proxylet'
code would be loaded into the targeted 'OPES intermediary' and be
'triggered' by the 'rules'.
Typical 'proxylet library' functions might include an HTML parser,
an HTML tree walker, cache read/write operators, archiving
functions, and logging operators. Typical 'proxylets' might
include a link replacement tool (e.g., mapping company names to
live stock quotes), a service menu insertion tool, a log analysis
tool, and a page synthesis tool. A 'proxylet' may invoke 'proxylet
library' functions or other 'proxylets' to complete an 'action'.
4.1.2.3 Remote Execution Environment: The Remote Call-out System
The 'remote call-out system' provides a remote execution
environment that allows content requests and responses to be
transformed or adapted by a 'remote call-out server'. Each
'remote call-out stub' provides the protocol interface between the
'OPES engine' and a 'remote call-out server'. Typical call-out
protocols include ICAP [8] and SOAP [9]. Remote operations run
Out-of-path.
Tomlinson, et. al. Expires May 20, 2002 [Page 19]
Internet-Draft OPES Model November 2001
Unlike 'proxylets', which are validated and executed in a local
environment, the 'remote call-out services' may be executed in a
different 'authoritative domain' and must be used with caution. For
example, an enterprise deploying 'OPES intermediaries' on the
intranet must make sure that no unauthorized 'remote call-out
services' are used on sensitive internal documents.
Editor Note: How does this relate to end-to-end encryption?
Also, we need to consider intermediary terminated encryption.
Examples of remote call-out services include URL filtering, language
translation, regional ad insertion, and content transformation for
mobile devices, etc.
4.2 Remote Call-out Servers
'Remote call-out servers' are usually employed in an OPES framework
to either offload the 'OPES intermediary' for better scalability or
to provide value-added services not available on either the
'origin server' or the 'OPES intermediary'.
Both the 'OPES admin server' and the 'remote call-out servers' are
typically not on the 'content path'. The 'OPES admin server' and
the 'OPES intermediary', however, usually belong to the same
'authoritative domain', while the placement of the 'remote call-out
servers' may depend on the design of the overlay networks. Section
4.4 and Section 4.5 describe a surrogate overlay and an delegate
overlay respectively, that place 'remote call-out servers' in the
same 'authoritative domain' with the 'OPES intermediary' and also
the 'origin server' or the 'client', respectively. Such overlay
networks simplify the administration and improve the security of
'actions' that involve 'remote call-out servers'.
4.3 OPES Admin Server
The 'OPES admin server' consists of the following logical
components: an authentication service, an authorization service,
and an accounting service. Collectively these services form the
operational control plane of an OPES ' content services network'.
4.3.1 Authentication Services
Authentication services provide authentication of devices comprising
an OPES ' content service network'. Minimally this includes OPES
authenticating 'OPES intermediaries' with an 'OPES admin server'.
Additionally, it includes 'remote call-out servers' with 'OPES
intermediaries', 'rule author' with the 'OPES admin server' and
'proxylet providers' with an 'OPES admin server'.
Tomlinson, et. al. Expires May 20, 2002 [Page 20]
Internet-Draft OPES Model November 2001
Authentication of 'content consumers' and 'origin servers' is not
provided by this service. This responsibility falls upon the
underlying content network. It is assumed 'OPES service modules'
will utilize the underlying content network authentication service
for these needs.
4.3.2 Authorization (Policy) Services
Authorization services as provided by the 'OPES admin server'
constitute a policy 'PDP' capability. This includes the
authorization of 'rule author' and 'proxylet providers' to provide
'rule modules' and 'proxylets' to the 'OPES admin server'.
Additionally, it includes the provisioning (i.e. downloading) of
validated 'rule modules' and 'proxylets' to 'OPES intermediaries'.
In addition to rules being provisioned via the 'OPES admin server',
they can be embedded within the content itself. An example of this
is Edge Side Includes[13]. Provisioning of these kinds of 'rules'
with an 'OPES engine' 'role' and the resultant insertion of 'content
services' in the message flow are subject to authorization by the
'OPES engine' 'PEP'.
4.3.3 Accounting Services
Accounting services provide collection of accounting and log data
from 'OPES intermediaries'. Such accounting and log data contains
measurement and recording of 'content service' activities,
especially when the information recorded is ultimately used as a
basis for the subsequent transfer of money, goods, or obligations.
4.4 Surrogate Overlays
A surrogate overlay is a specific type of 'content service
network', which is delegated the authority to provide 'content
services' on behalf of, and typically in close co-operation with,
one or more 'origin servers'. Surrogate overlays can be seen as
logical extension of 'origin servers'.
The elements of surrogate overlays (e.g. the 'OPES intermediaries'
or the 'remote call-out servers') act on behalf of 'origin severs'
and logically belong to the 'authoritative domain' of the respective
'origin servers' (see Figure 6). In particular, services in
surrogate overlays are authorized by the content owner through the
'OPES admin server'.
Tomlinson, et. al. Expires May 20, 2002 [Page 21]
Internet-Draft OPES Model November 2001
*********************************************
* *
* +--------+ Authoritative *
* | Origin | Domain *
* | Server | *
* +--------+ +------------+ *
* | | OPES Admin | *
* | | Server | *
* | +------------+ *
* | / *
* | / *
* +--------------+ +-----------------+ *
* | OPES |----- | Remote Call-out | *
* | Intermediary | | Server | *
* +--------------+ +-----------------+ *
* | *
*********************************************
|
|
|
+--------+
| Client |
+--------+
Figure 6. Authoritative Domains for Surrogate Overlays
Surrogate overlays provide services that would otherwise be run by
the content provider at the 'origin server'. Such services include,
but are not limited to, dynamic assembling of web pages,
watermarking, and content adaptation. For illustration purposes, we
will consider a content provider offering web pages that include a
local weather forecast based on the client preferences (which can be
transmitted in form of a cookie or any other suitable form).
Typically, the content provider would run such a service at the
'origin server'. The service would analyze received requests and
associated user preferences, select appropriate templates, insert
the corresponding local weather forecasts, and would then deliver
the content to the 'client'. This is all done at the 'origin server'
and authorized/controlled by the content provider. In case of
surrogate overlays, the same service can be run on either an 'OPES
intermediary' (local execution) or a 'remote call-out server'
(remote execution). For this purpose, the content provider contacts
the 'OPES admin server' and explicitly authorizes 'OPES
intermediaries' in the 'content path' to perform the service on its
behalf (or to commission a call-out server to perform the service on
its behalf).
Note: for more information on Surrogate scenarios see [11].
Tomlinson, et. al. Expires May 20, 2002 [Page 22]
Internet-Draft OPES Model November 2001
4.5 Delegate Overlays
A delegate overlay is a specific type of 'content service network',
which is delegated the authority to provide 'content services' on
behalf of, and typically in close co-operation with, one or more
'content consumers'. Delegate overlays can be seen as logical
extension of 'user agents'.
The elements of delegate overlays (e.g. the 'OPES intermediary' or
the 'remote call-out servers') act on behalf of 'content consumers'
and logically belong to the 'authoritative domain' of the respective
'clients' (see Figure 7). In particular, services in delegate
overlays are authorized by the 'content consumer' through the 'OPES
admin server'.
+--------+
| Origin |
| Server |
+--------+
|
|
|
*********************************************
* | *
* +--------------+ +-----------------+ *
* | OPES |----- | Remote Call-out | *
* | Intermediary | | Server | *
* +--------------+ +-----------------+ *
* | \ *
* | +------------+ *
* | | OPES Admin | *
* | | Server | *
* | +------------+ *
* +--------+ *
* | Client | Authoritative *
* +--------+ Domain *
* *
*********************************************
Figure 7. Authoritative Domains for Delegate Overlays
Tomlinson, et. al. Expires May 20, 2002 [Page 23]
Internet-Draft OPES Model November 2001
Delegate overlays provide services that would otherwise be run by
the 'content consumer' on his local machine. Such services include,
but are not limited to, virus scanning and content filtering. For
illustration purposes, we will consider a 'content consumer' taking
advantage of virus scanning software. Typically, the 'content
consumer' would run the virus scanning software on his local
machine. The service would scan received content for viruses and
block infected files to protect the user. This is all done at the
'client' and authorized/controlled by the 'content consumer'. In
case of delegate overlays, the same service can be run on either an
'OPES intermediary' (local execution) or a 'remote call-out server'
(remote execution). For this purpose, the 'content consumer'
contacts the 'OPES admin server' and explicitly authorizes 'OPES
intermediaries' in the 'content path' to perform the service on its
behalf (or to commission a call-out server to perform the service on
its behalf). More information on Delegate scenarios see [11].
5. End-to-End Data Integrity
The architectural principles of OPES type devices and content
service networks must protect the end-to-end data integrity in
the Internet. In particular, the robustness long cited as one
of the overriding goals of the Internet architecture [19] must
be respected. These concerns were addressed by the IAB in [18]
and by OPES in [20]. In [16,17], a framework for ensuring the
data integrity, security and privacy for OPES based networks are
discussed.
This section discusses the guidelines that must be followed
during the design of content services networks to ensure that the
end-to-end data integrity is achieved. The work does not develop
specific model or protocols. However, the guidelines may require the
development of new approaches that could be used to ensure the
integrity of data in networks with distributed intelligence.
5.1 Requirements for End-to-End Data Integrity
The design of OPES intermediaries and any overlay networks that are
based on such devices must be based on the requirements that are
discussed next.
5.1.1 One-party consent
The use of any OPES service must be explicitly authorized by AT LEAST
one of the application-layer end-hosts. This means that either the
content provider or the client or both must explicitly agree on the
OPES service. This can be achieved through the following [20]:
- An extensible content providers "Permissions" format for use by
content providers must be defined indicating what parts of content
can be modified and what modifications are allowed. This must allow
different permissions for different resources.
Tomlinson, et. al. Expires May 20, 2002 [Page 24]
Internet-Draft OPES Model November 2001
- A means for OPES Intermediaries to fetch Content Providers Intermediaries
Permissions documents must be provided.
- A means for content provider to decline the services of an OPES
Intermediaries.
5.1.2 IP-layer communications
The presence of OPES Intermediaries MUST NOT be hidden from the user
or the client (i.e. content consumer). In this regard, the client
and/or the content provider must be able to explicitly address the
OPES Intermediaries at the IP layer.
5.1.3 Notification
Implementers of OPES Intermediaries should assist content providers
in developing schemes that enable them to detect inappropriate
behavior of such devices. This can be achieved through the use of
the following:
- Developing a format for use at a Web site to associate digital
signatures with parts or all of the content. This can enable content
consumers (end user or client) to check/verify content integrity to
ensure parts of content not intended to be transformed have been left
unchanged. An example of such method is given in [17]. Similarly, it
is possible to use a scheme that is similar to W3C Signatures [21].
- A mechanism for creating temporary versions of the integrity check
format for dynamically created content should be developed.
- A mechanism should be developed to allow end users (i.e. content
consumers) (or others) to retrieve integrity checking information
for resources from a Web Site. One mechanism for retrieving this
information is placement at a well-known place on the Web site
(similar to P3P [22]).
5.1.4 Non-blocking
The design of OPES Intermediaries must allow end users to request
and receive a Non OPES version of the content if available. To fulfill
this requirement extensions to current schemes for requesting data may
be required.
Editor Note: Need to incorporate that specific rules might also
be an approach to address this issue. For example, IRML allows
the specification of "negative rules", i.e. if a certain condition
matches, do NOT do the listed actions. A content provider could
specify such rules for his/her non-OPES versions (e.g. if URL is for
non-OPES version, never do OPES service).
Tomlinson, et. al. Expires May 20, 2002 [Page 25]
Internet-Draft OPES Model November 2001
5.1.5 Privacy
OPES Intermediaries must respect the following rule regarding privacy
- OPES Intermediaries must not violate a Web site's W3C P3P policy
applicable to a resource (P3P policy are found at the Content
Providers Web Site).
- OPES Intermediaries must honor both End User (i.e. content consumer)
and Content Provider Intermediaries Privacy policies.
Furthermore, as discussed in [20], appropriate schemes should be
developed that allow:
- Users (i.e. content consumers) /or Content Providers to define
additional privacy requirements that apply to Intermediaries in
an Intermediaries Privacy policy. Note that P3P describes privacy
policy end to end, but a more restrictive privacy policy may be
desirable at Intermediaries. The Intermediaries Privacy Policy must
include the ability to specify what information can be recorded by
Intermediaries and how it is used.
- Establishing a mechanism for OPES Intermediaries to access a
Content Provider's Intermediaries Privacy policy. One method for
Content Providers must be to place an Intermediaries Privacy policy
document at a well known place on their Web site.
- Establishing a mechanism for OPES Intermediaries to receive an
end user's (i.e. content consumer)Intermediaries Privacy policy.
- Establishing a mechanism for OPES Intermediaries to be able to
specify what information Intermediaries can or cannot record,
including cookies, IP addresses, HTTP header fields and how they
can use that information.
- Establishing a mechanism for OPES Intermediaries to be able to
specify what information can or cannot be passed by OPES
Intermediaries to OPES callout services, including cookies,
IP addresses, HTTP header fields.
- Establishing a mechanism for OPES Intermediaries to be able
to specify what information has been recorded. This information
must be passed to the Content Provider on requests (if required
by the Content Provider's Intermediary Privacy policy) and must
also be returned to the End User in responses (default, even
when no End User (content consumer) Intermediaries Privacy
Policy is available).
- OPES Intermediaries Privacy policies must be able to specify
that OPES Intermediaries should pass through requests or responses
without OPES callouts.
Tomlinson, et. al. Expires May 20, 2002 [Page 26]
Internet-Draft OPES Model November 2001
6. Security Considerations
Security concerns with respect to ' content service networks' can be
generally categorized into trust within the system and protection of
the system from threats. The trust model utilized within OPES is
predicated largely on transitive trust between the underlying
Content Network, 'OPES Intermediaries', 'OPES admin servers', and
'remote call-out servers'. Network elements within the OPES 'edge
service network' are considered to be "insiders" and therefore
trusted. Given the transitive trust afforded to "insiders", it is
necessary to mutually authenticate the identities of network
elements belonging to an OPES 'edge service network'.
6.1 Threats to the underlying Content Network
The OPES ' content service network' is predicated upon an
underlying network to secure the 'content path'. Thus, threats to
the underlying network pose threats to the OPES 'content services
network'. The principal threat being the compromising of an edge
server hosting an OPES Intermediary.
6.2 Threats to the OPES Content Services Network
If an 'OPES admin server' is breached, the attacker can gain control
of the entire OPES ' content services network'.
If the communication channel between the 'OPES admin server' and the
'OPES intermediary' is breached, the attacker can gain control of a
subset of the OPES ' content services network'.
If the 'OPES admin server' fails to authenticate and/or authorize
either 'rule authors' or 'proxylet providers', rights of the
principal parties could be violated along with unintentional or
malicious interference.
6.3 Threats to the Local Execution Environment
If 'rules' are not prevented from triggering on unauthorized
contents flows, rights of the principal parties will likely be
violated, including but not limited to copyright and privacy.
If a 'proxylet' is able to access system resources outside of its
authorized "sandbox", unintentional or malicious interference could
occur, including not only rights violations but the possibility of
compromising the 'OPES intermediary'.
Tomlinson, et. al. Expires May 20, 2002 [Page 27]
Internet-Draft OPES Model November 2001
6.4 Threats to the Remote Execution Environment
If a 'remote call-out server' is compromised, rights of the
principal parties could be violated, including but not limited to
copyright, privacy and confidentiality.
'Remote call-outs' may inadvertently or maliciously expose private
information (passwords, buying patterns, page views, credit card
numbers) as it transits to and from 'remote call-out servers'.
If the communication channel between the 'OPES intermediary' and the
'remote call-out server' is snooped, the attacker may gain access to
sensitive information. In this case, sensitive content should
always be encrypted between these two parties, even if they trust
each other.
7. Acknowledgements
The authors acknowledge the contributions of influential precursor
works done by Andre Beck, Michael Condry, Rob Erickson, Dave Farber,
James Kempf, Christian Maciocco, Hilarie Orman, Nalin Mistry and
Lily Yang.
References
[1] Postel, J., "Internet Protocol", RFC 791, September 1981,
<URL:http://www.rfc-editor.org/rfc/rfc791.txt>.
[2] Hares, S. and D. Katz, "Administrative Domains and Routing
Domains A Model for Routing in the Internet", RFC 1136,
December 1989,
<URL:http://www.rfc-editor.org/rfc/rfc1136.txt>.
[3] Carpenter, B., "Architecture Principles of the Internet", RFC
1958, June 1996,
<URL:http://www.rfc-editor.org/rfc/rfc1958.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,
<URL:http://www.rfc-editor.org/rfc/rfc2616.txt>.
[5] Carpenter, B., "Internet Transparency", RFC 2775, February
2000, <URL:http://www.rfc-editor.org/rfc/rfc2775.txt>.
[6] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, January 2001,
<URL:http://www.ietf.org/rfc/rfc3040.txt>.
Tomlinson, et. al. Expires May 20, 2002 [Page 28]
Internet-Draft OPES Model November 2001
[7] Beck, A. and M. Hofmann, "IRML: A Rule Specification Language
for Intermediary Services", draft-beck-opes-irml-01.txt (work
in progress), July 2001,
<URL:http://www.ietf.org/internet-drafts/draft-beck-opes-irml-
01.txt>.
[8] Elson, J. and A. Cerpa, "ICAP the Internet Content Adaptation
Protocol", ICAP Forum
http://www.circlemud.org/~jelson/icap-1.72.txt,
Work in progress, June 2001,
<URL:http://www.circlemud.org/~jelson/icap-1.72.txt>.
[9] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn,
N., Frystyk Nielsen, H., Thatte, S. and D. Winer, "Simple
Object Access Protocol (SOAP) 1.1", W3C Note
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/, May 2000,
<URL:http://www.w3.org/TR/2000/NOTE-SOAP-20000508/>.
[10] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Perry, J., Herzog, S., Huynh, A., Carlson, M. and
S. Waldbusser, "Policy Terminology",
draft-ietf-policy-terminology-04.txt (work in progress),
July 2001,
<URL:http://www.ietf.org/internet-drafts/draft-ietf-policy-
terminology-04.txt>.
[11] McHenry, S., Condry, M. and G. Tomlinson, "Open Pluggable Edge
Services Use Cases and Deployment Scenarios",
draft-mchenry-opes-deployment-scenarios-00.txt (work in
progress), July 2000,
<URL:http://www.ietf.org/internet-drafts/draft-mchenry-opes-
deployment-scenarios-00.txt>.
[12] Rafalow, L., Yang, L. and A. Beck, "Policy Requirements for
Edge Services", draft-rafalow-opes-policy-requirements-00.txt
(work in progress), July 2001,
<URL:http://www.ietf.org/internet-drafts/draft-rafalow-opes-
policy-requirements-00.txt>.
[13] Nottingham, M., Tsimelzon, M., Weihl, B. and L. Jacobs, "ESI
Language Specification 1.0", EDGE SIDE INCLUDES
http://www.esi.org/language_spec_1-0.html, May 2001,
<URL:http://www.esi.org/language_spec_1-0.html>.
[14] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A.
Rayhan, "Middlebox Communication Architecture and framework",
draft-ietf-midcom-framework-03.txt, work in progress.
[15] R. Penno, A. Rayhan, M. Duffy, "Out-Of-Path (OOP) Agents and
MIDCOM Framework Integration", draft-penno-midcom-oop-00.txt,
work in progress.
Tomlinson, et. al. Expires May 20, 2002 [Page 29]
Internet-Draft OPES Model November 2001
[16] A. Barbir et al, " A Framework for OPES End to End Data
Integrity: Virtual Private Content Networks (VPCN)",
draft-barbir-opes-vpcn-00.txt, Work in Progress, November 2001,
URL:http://www.ietf.org/internet-drafts/
draft-barbir-opes-vpcn-00.txt.
[17] Hillary Orman, "Data Integrity in an Active Content System",
http://www.cs.utah.edu/~horman/opes.html.
[18] S. Floyd et al, "IAB Architectural and Policy Considerations for
OPES ",draft-iab-opes-01.txt, work in progress, October 2001.
URL:http://www.ietf.org/internet-drafts/draft-iab-opes-01.txt>
[19] David D. Clark, The Design Philosophy of the DARPA Internet
Protocols, SIGCOMM 1988.
[20] Wayne Carr, ``Suggested OPES Requirements for Integrity,
Privacy and Security'', email to ietf-openproxy@imc.org,
August 16, 2001. URL ``http://www.imc.org/ietf-openproxy/
mail-archive/msg00869.html''.
[21] Eastlake, D., Reagle, J., Solo, D., Bartel, M., Boyer, J.,
Fox, B., LaMacchia, B. and E. Simon, "XML-Signature Syntax
and Processing", W3C Proposed Recommendation, work in progress,
August 20001,
URL:http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/>
[22] Cranor, L., Langheinrich, M., Massimo, M., Presler-Marshall,
M. and J. Reagle, "The Platform for Privacy Preferences 1.0
(P3P1.0) Specification", W3C Note, work in progress,
September 2001,
<URL:http://www.w3.org/TR/2001/WD-P3P-20010928/>
Authors' Addresses
Gary Tomlinson
CacheFlow Inc.
Suite 201
12034 134th Ct. NE
Redmond, WA 98052 US
Phone: +1 425 820 3009
EMail: garyt@cacheflow.com
Robin Chen
AT&T Research
Room E219
180 Park Avenue
Florham Park, NJ 07932 US
Phone: +1 973 360 8653
EMail: chen@research.att.com
Tomlinson, et. al. Expires May 20, 2002 [Page 30]
Internet-Draft OPES Model November 2001
Markus Hofmann
Bell Labs/Lucent Technologies
Room 4F-513
101 Crawfords Corner Road
Holmdel, NJ 07733 US
Phone: +1 732 332 5983
EMail: hofmann@bell-labs.com
Reinaldo Penno
Nortel Networks, Inc.
2305 Mission College Boulevard
Building SC9-B1240
San Jose, CA 95134
Email: rpenno@nortelnetworks.com
Abbie Barbir, Ph.D.
Nortel Networks
3500 Carling Avenue
Nepean Ontario K2H 8E9 Canada
Email: abbieb@nortelnetworks.com
Tomlinson, et. al. Expires May 20, 2002 [Page 31]
Internet-Draft OPES Model November 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Tomlinson, et. al. Expires May 20, 2002 [Page 32]