Open Pluggable Edge Services (OPES)
MEMBER BRIEFING 5 < Main Index
|December 2001||By Sally Floyd and Leslie Daigle|
Open Pluggable Edge Services (OPES) are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client, that would transform or filter content. Examples of proposed OPES services include assembling personalized web pages, adding user-specific regional information to web pages, virus scanning, content adaptation for clients with limited bandwidth, language translation, among other applications.
The question of chartering OPES in the Internet Engineering Task Force (IETF) and the related controversy in the IETF community have raised to the fore several architectural and policy issues about robustness and the end-to-end integrity of data. One view on OPES has been that "OPES is deeply evil and the IETF should stay far, far away from this hideous abomination." Others have suggested that "OPES would reduce both the integrity, and the perception of integrity, of communications over the Internet, and would significantly increase uncertainly about what might have been done to content as it moved through the network," and that therefore the risks of OPES outweigh the benefits.
A natural first question is whether there is any architectural benefit to putting specific services inside the network (e.g., at the application-level web cache) instead of positioning all services either at the content provider or the end user. It seems clear that there can indeed be significant architectural benefit in providing some OPES services inside the network at the application-level OPES intermediary. For example, if some content is already available from a local or regional web cache, and the end user requires some transformation (such as adaptation to a limited- bandwidth path) applied to that data, providing that service at the web cache itself can prevent the wasted bandwidth of having to retrieve more data from the content provider, and at the same time avoid unnecessary delays in providing the service to the end user.
Further questions concern whether the architectural benefits of providing services in the middle of the network outweigh the architectural costs, such as the potential costs concerning data integrity, and whether an OPES service, designed primarily for a single retrieval action, has an impact on the application layer addressing architecture. OPES has raised a number of important questions regarding integrity, privacy, and security. In particular, it seems unavoidable that at some point in the future some OPES service will perform inappropriately (e.g., a virus scanner rejecting content that does not include a virus), and some OPES intermediary will be compromised either inadvertently or with malicious intent. Given this, it seems necessary for the overall architecture to help protect end-to-end data integrity by addressing, from the beginning of the design process, the requirement of helping end hosts to detect and respond to inappropriate behavior by OPES intermediaries. One of the goals of the OPES architecture must be to maintain the robustness long cited as one of the overriding goals of the Internet architecture. Given this, it has been recommended that the IESG require that the OPES architecture protect end-to-end data integrity by supporting end-host detection and response to inappropriate behavior by OPES intermediaries.
One-party consent, with one of the end-hosts explicitly authorizing the OPES service, must be a requirement for OPES to be standardized in the IETF. However, the one-party consent model by itself (e.g., with one of the end-hosts authorizing the OPES service, and the other end- host perhaps being unaware of the OPES service) is insufficient for protecting data integrity in the network. We also agree with others that, regardless of the security and authorization mechanisms standardized for OPES in the IETF, OPES implementations could probably be modified to circumvent these mechanisms, resulting in the unauthorized modification of content. Still, this is true of many protocols considered by the IETF, and by itself should not represent a compelling reason not to standardize transport protocols, routing protocols, web caching protocols, or OPES itself. Instead, the infrastructure needs, as much as possible, to be designed to detect and defend itself against compromised implementations, and misuses of protocols need to be addressed directly, each in the appropriate venue.
Mechanisms such as digital signatures, which help users to verify for themselves that content has not been altered, are a first step towards the detection of the unauthorized modification of content in the network. However, in the case of OPES, additional protection to ensure the end-to-end integrity of data is desirable as well, for example, to help end-users to detect cases where OPES intermediaries are authorized to modify content, but perform inappropriate modifications.
If OPES is chartered, the OPES working group will also have to explicitly decide and document whether the OPES architecture must be compatible with the use of encryption by one or more ends of an OPES-involved session. If OPES was compatible with encryption, this would effectively ensure that OPES boxes would be restricted to ones that are known, trusted, explicitly addressed at the IP layer, and authorized (by the provision of decryption keys) by at least one of the ends. Compatibility with encryption would also help to prevent the widespread deployment of yet another set of services that, to benefit from, require one to keep one's packet contents in the clear for all to snoop.
The Internet Architecture Board (IAB) has made the following recommendations about chartering OPES in the IETF:
An OPES framework standardized in the IETF must require that the
use of any OPES service be explicitly authorized by one of the
application-layer end-hosts (that is, either the content provider
or the client). For an OPES framework standardized in the IETF,
the OPES intermediary must be explicitly addressed at the IP layer
by the end user. The overall OPES framework needs to assist content
providers in detecting and responding to client-centric actions
by OPES intermediaries that are deemed inappropriate by the content
provider. The overall OPES framework should assist end users in
detecting the behavior of OPES intermediaries, potentially allowing
them to identify imperfect or compromised intermediaries. If there
exists a "non-OPES" version of content available from the content
provider, the OPES architecture must not prevent users from retrieving
this "non-OPES" version from the content provider. OPES documentation
must be clear in describing these services as being applied to
the result of URI resolution, not as URI resolution itself. All
proposed services must define their impact on inter- and intra-document
reference validity. The overall OPES framework must provide for
mechanisms for end users to determine the privacy policies of
For More Information
Relevant IETF RFCs
Many IETF RFCs are relevant to the discussion of OPES. Visit the RFC Editor page for more information
Examples in the News
About the Author
Sally Floyd is a senior scientist at ACIRI, the AT&T Center for
Internet Research at ICSI. Her research interests include congestion
control in computer networks and the analysis of network dynamics.
Among other activities, she is a member of the Internet Architecture
The ISOC Member Briefing series is made possible through the generous assistance of ISOC's Platinum Program Sponsors: Afilias, APNIC, ARIN, Microsoft, and the RIPE NCC, Sida. More information on the Platinum Sponsorship Program...
About the Background Paper Series
4, rue des Falaises
Series Editor: Martin Kupres
Copyright C Internet Society 2005.