Request for Comments: 3835 R. Penno
Category: Informational Nortel Networks
R. Chen
AT&T Labs
M. Hofmann
Bell Labs/Lucent Technologies
H. Orman
Purple Streak Development
August 2004
An Architecture for Open Pluggable Edge Services (OPES)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo defines an architecture that enables the creation of an
application service in which a data provider, a data consumer, and
zero or more application entities cooperatively implement a data
stream service.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 . The Architecture . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. OPES Entities. . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Data Dispatcher. . . . . . . . . . . . . . . . . 5
2.2. OPES Flows . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. OPES Rules . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Callout Servers. . . . . . . . . . . . . . . . . . . . . 7
2.5. Tracing Facility . . . . . . . . . . . . . . . . . . . . 8
3. Security and Privacy Considerations . . . . . . . . . . . . . 9
3.1. Trust Domains. . . . . . . . . . . . . . . . . . . . . . 9
3.2. Establishing Trust and Service Authorization . . . . . . 11
3.3. Callout Protocol . . . . . . . . . . . . . . . . . . . . 11
3.4. Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. End-to-end Integrity . . . . . . . . . . . . . . . . . . 12
4. IAB Architectural and Policy Considerations for OPES . . . . . 12
4.1. IAB consideration (2.1) One-party Consent. . . . . . . . 12
4.2. IAB consideration (2.2) IP-Layer Communications. . . . . 13
4.3. IAB consideration (3.1 and 3.2) Notification . . . . . . 13
4.4. IAB consideration (3.3) Non-Blocking . . . . . . . . . . 13
4.5. IAB consideration (4.1) URI Resolution . . . . . . . . . 13
4.6. IAB consideration (4.2) Reference Validity . . . . . . . 13
4.7. IAB consideration (4.3) Application Addressing
Extensions . . . . . . . . . . . . . . . . . . . . . . . 14
4.8. IAB consideration (5.1) Privacy. . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 16
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
1. Introduction
When supplying a data stream service between a provider and a
consumer, the need to provision the use of other application
entities, in addition to the provider and consumer, may arise. For
example, some party may wish to customize a data stream as a service
to a consumer. The customization step might be based on the
customer’s resource availability (e.g., display capabilities).
In some cases it may be beneficial to provide a customization service
at a network location between the provider and consumer host rather
than at one of these endpoints. For certain services performed on
behalf of the end-user, this may be the only option of service
deployment. In this case, zero or more additional application
entities may participate in the data stream service. There are many
possible provisioning scenarios which make a data stream service
attractive. The OPES Use Cases and Deployment Scenarios [1] document
provides examples of OPES services. The document discusses services
that modify requests, services that modify responses, and services
that create responses. It is recommended that the document on OPES
Use Cases and Deployment Scenarios [1] be read before reading this
document.
This document presents the architectural components of Open Pluggable
Edge Services (OPES) that are needed in order to perform a data
stream service. The architecture addresses the IAB considerations
described in [2]. These considerations are covered in various parts
of the document. Section 2.5 addresses tracing; section 3 addresses
security considerations. Section 4 provides a summary of IAB
considerations and how the architecture addresses them.
The document is organized as follows: Section 2 introduces the OPES
architecture. Section 3 discusses OPES security and privacy
considerations. Section 4 addresses IAB considerations for OPES.
Section 5 discusses security considerations. Section 6 addresses
IANA considerations. Section 7 provides a summary of the
architecture and the requirements for interoperability.
2. The Architecture
The architecture of Open Pluggable Edge Services (OPES) can be
described in terms of three interrelated concepts, mainly:
o OPES entities: processes operating in the network;
o OPES flows: data flows that are cooperatively realized by the
OPES entities; and,
o OPES rules: these specify when and how to execute OPES services.
2.1. OPES Entities
An OPES entity is an application that operates on a data flow between
a data provider application and a data consumer application. OPES
entities can be:
o an OPES service application, which analyzes and possibly
transforms messages exchanged between the data provider
application and the data consumer application;
o a data dispatcher, which invokes an OPES service application based
on an OPES ruleset and application-specific knowledge.
The cooperative behavior of OPES entities introduces additional
functionality for each data flow provided that it matches the OPES
rules. In the network, OPES entities reside inside OPES processors.
In the current work, an OPES processor MUST include a data
dispatcher. Furthermore, the data provider and data consumer
applications are not considered as OPES entities.
To provide verifiable system integrity (see section 3.1 on trust
domains below) and to facilitate deployment of end-to-end encryption
and data integrity control, OPES processors MUST be:
o explicitly addressable at the IP layer by the end user (data
consumer application). This requirement does not preclude a chain
of OPES processors with the first one in the chain explicitly
addressed at the IP layer by the end user (data consumer
application).
o consented to by either the data consumer or data provider
application. The details of this process are beyond the scope of
the current work.
The OPES architecture is largely independent of the protocol that is
used by the data provider application and the data consumer
application to exchange data. However, this document selects HTTP
[3] as the example for the underlying protocol in OPES flows.
2.1.1. Data Dispatcher
Data dispatchers include a ruleset that can be compiled from several
sources and MUST resolve into an unambiguous result. The combined
ruleset enables an OPES processor to determine which service
applications to invoke for which data flow. Accordingly, the data
dispatcher constitutes an enhanced policy enforcement point, where
policy rules are evaluated and service-specific data handlers and
state information are maintained, as depicted in Figure 1.
+----------+
| callout |
| server |
+----------+
||
||
||
||
+--------------------------+
| +-----------+ || |
| | OPES | || |
| | service | || |
| |application| || |
| +-----------+ || |
| +----------------------+ |
OPES flow <---->| | data dispatcher and | |<----> OPES flow
| | policy enforcement | |
| +----------------------+ |
| OPES |
| processor |
+--------------------------+
Figure 1: Data Dispatchers
The architecture allows for more than one policy enforcement point to
be present on an OPES flow.
2.2. OPES Flows
An OPES flow is a cooperative undertaking between a data provider
application, a data consumer application, zero or more OPES service
applications, and one or more data dispatchers.
Since policies are enforced by data dispatchers, the presence of at
least one data dispatcher is required in the OPES flow.
data OPES OPES data
consumer processor A processor N provider
+-----------+ +-----------+ . +-----------+ +-----------+
| data | | OPES | . | OPES | | data |
| consumer | | service | . | service | | provider |
|application| |application| . |application| |application|
+-----------+ +-----------+ . +-----------+ +-----------+
| | | | . | | | |
| HTTP | | HTTP | . | HTTP | | HTTP |
| | | | . | | | |
+-----------+ +-----------+ . +-----------+ +-----------+
| TCP/IP | | TCP/IP | . | TCP/IP | | TCP/IP |
+-----------+ +-----------+ . +-----------+ +-----------+
|| || || . || || ||
================ =====.======== ===========
| <----------------- OPES flow -------------------> |
Figure 2: An OPES flow
Figure 2 depicts two data dispatchers that are present in the OPES
flow. The architecture allows for one or more data dispatchers to be
present in any flow.
2.3. OPES Rules
OPES’ policy regarding services and the data provided to them is
determined by a ruleset consisting of OPES rules. The rules consist
of a set of conditions and related actions. The ruleset is the
superset of all OPES rules on the processor. The OPES ruleset
determines which service applications will operate on a data stream.
In this model, all data dispatchers are invoked for all flows.
In order to ensure predictable behavior, the OPES architecture
requires the use of a standardized schema for the purpose of defining
and interpreting the ruleset. The OPES architecture does not require
a mechanism for configuring a ruleset into a data dispatcher. This
is treated as a local matter for each implementation (e.g., through
the use of a text editor or a secure upload protocol), as long as
such a mechanism complies with the requirements set forth in section
3.
2.4. Callout Servers
The evaluation of the OPES ruleset determines which service
applications will operate on a data stream. How the ruleset is
evaluated is not the subject of the architecture, except to note that
it MUST result in the same unambiguous result in all implementations.
In some cases it may be useful for the OPES processor to distribute
the responsibility of service execution by communicating with one or
more callout servers. A data dispatcher invokes the services of a
callout server by using the OPES callout protocol (OCP). The
requirements for the OCP are given in [5]. The OCP is application-
agnostic, being unaware of the semantics of the encapsulated
application protocol (e.g., HTTP). However, the data dispatcher MUST
incorporate a service aware vectoring capability that parses the data
flow according to the ruleset and delivers the data to either the
local or remote OPES service application.
The general interaction situation is depicted in Figure 3, which
illustrates the positions and interaction of different components of
OPES architecture.
+--------------------------+
| +-----------+ |
| | OPES | |
| | service | | +---------------+ +-----------+
| |application| | | Callout | | Callout |
| +-----------+ | | Server A | | Server X |
| || | | +--------+ | | |
| +----------------------+ | | | OPES | | | |
| | data dispatcher | | | | Service| | | +--------+|
| +----------------------+ | | | Appl A | | | | OPES ||
| || || | | +--------+ | | |Service ||
| +---------+ +-------+ | | || | | | Appl X ||
| | HTTP | | | | | +--------+ | ... | +--------||
| | | | OCP |=========| | OCP | | | || |
| +---------+ +-------+ | | +--------+ | | +------+ |
| | | || | +---------------+ | | OCP | |
| | TCP/IP | =======================================| | |
| | | | | +------+ |
| +---------+ | +-----------+
+--------||-||-------------+
|| ||
+--------+ || || +--------+
|data |== =========================================|data |
|producer| |consumer|
+--------+ +--------+
Figure 3: Interaction of OPES Entities
2.5. Tracing Facility
The OPES architecture requires that each data dispatcher provides
tracing facilities that allow the appropriate verification of its
operation. The OPES architecture requires that tracing be feasible
on the OPES flow, per OPES processor, using in-band annotation. One
of those annotations could be a URI with more detailed information on
the OPES services being executed in the OPES flow.
Providing the ability for in-band annotation MAY require header
extensions on the application protocol that is used (e.g., HTTP).
However, the presence of an OPES processor in the data request/
response flow SHALL NOT interfere with the operations of non-OPES
aware clients and servers. Non-OPES clients and servers need not
support these extensions to the base protocol.
OPES processors MUST obey tracing, reporting, and notification
requirements set by the center of authority in the trust domain to
which an OPES processor belongs. As part of these requirements, the
OPES processor may be instructed to reject or ignore such
requirements that originate from other trust domains.
3. Security and Privacy Considerations
Each data flow MUST be secured in accordance with several policies.
The primary stakeholders are the data consumer and the data provider.
The secondary stakeholders are the entities to which they may have
delegated their trust. The other stakeholders are the owners of the
callout servers. Any of these parties may be participants in the
OPES flow.
These parties MUST have a model, explicit or implicit, describing
their trust policy, which of the other parties are trusted to operate
on data, and what security enhancements are required for
communication. The trust might be delegated for all data, or it
might be restricted to granularity as small as an application data
unit.
All parties that are involved in enforcing policies MUST communicate
the policies to the parties that are involved. These parties are
trusted to adhere to the communicated policies.
In order to delegate fine-grained trust, the parties MUST convey
policy information by implicit contract, by a setup protocol, by a
dynamic negotiation protocol, or in-line with application data
headers.
3.1. Trust Domains
The delegation of authority starts at either a data consumer or data
provider and moves to more distant entities in a "stepwise" fashion.
Stepwise means A delegates to B, and B delegates to C, and so forth.
The entities thus "colored" by the delegation are said to form a
trust domain with respect to the original delegating party. Here,
"Colored" means that if the first step in the chain is the data
provider, then the stepwise delegation "colors" the chain with that
data "provider" color. The only colors defined are the data
"provider" and the data "consumer". Delegation of authority
(coloring) propagates from the content producer start of authority or
from the content consumer start of authority, which may be different
from the end points in the data flow.
Figure 4 illustrates administrative domains, out-of-band rules, and
policy distribution.
provider administrative domain consumer administrative domain
+------------------------------+ +-------------------------------+
| +--------------+ | | +--------------+ |
| |Provider | <- out-of-band rules, -> |Consumer | |
| |Administrative|~~>~~~: policies and ~<~|Administrative| |
| |Authority | : service authorization : |Authority | |
| +--------------+ : | | : +--------------+ |
| : : | | : : |
| : : | | : : |
| +----------+ : | | : +----------+ |
| | callout | +---------+ | | +---------+ | callout | |
| | server |====| | | | | |====| server | |