IAB Architectural and Policy Considerations for Open Pluggable Edge Services
RFC 3238
| Document | Type |
RFC - Informational
(January 2002; No errata)
Was draft-iab-opes
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IAB | ||
| Formats | plain text pdf html bibtex | ||
| Stream | IAB state | (None) | |
| Consensus Boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
Network Working Group Internet Architecture Board (IAB)
Request for Comments: 3238 S. Floyd
Category: Informational L. Daigle
January 2002
IAB Architectural and Policy Considerations for
Open Pluggable Edge Services
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 (2002). All Rights Reserved.
Abstract
This document includes comments and recommendations by the IAB on
some architectural and policy issues related to the chartering of
Open Pluggable Edge Services (OPES) in the IETF. 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. These intermediaries would transform or filter
content, with the explicit consent of either the content provider or
the end user.
1. Introduction
Open Pluggable Edge Services (OPES) are services that would be
deployed 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, and the like [OPES].
The question of chartering OPES in the IETF ([OPESBOF1], [OPESBOF2],
[OPESBOF3]) and the related controversy in the IETF community
([Carr01], [CDT01], [Morris01], [Orman01], [Routson01]) have raised
to the fore several architectural and policy issues about robustness
and the end-to-end integrity of data (in terms of the disparities
between what the "origin server" makes available and what the client
receives). In particular, questions have been raised about the
possible requirements, for a protocol to be developed and
IAB Informational [Page 1]
RFC 3238 IAB Considerations for OPES January 2002
standardized in the IETF, for that protocol to protect the end-to-end
privacy and integrity of data. This document attempts to address
some of the architectural and policy issues that have been unresolved
in the chartering of OPES, and to come to some common recommendations
from the IAB regarding these issues.
The purpose of this document is not to recommend specific solutions
for OPES, or even to mandate specific functional requirements. This
is also not a recommendation to the IESG about whether or not OPES
should be chartered. Instead, these are recommendations on issues
that any OPES solutions standardized in the IETF should be required
to address, similar to the "Security Considerations" currently
required in IETF documents [RFC2316]. As an example, one way to
address security issues is to show that appropriate security
mechanisms have been provided in the protocol, and another way to
address security issues is to demonstrate that no security issues
apply to this particular protocol. (Note however that a blanket
sentence that "no security issues are involved" is never considered
sufficient to address security concerns in a protocol with known
security issues.)
This document will try to make our concerns underlying integrity,
privacy, and security as clear as possible. We recommend that the
IESG require that OPES documents address integrity, privacy, and
security concerns in one way or another, either directly by
demonstrating appropriate mechanisms, or by making a convincing case
that there are no integrity or privacy concerns relevant to a
particular document.
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 [Clark88]. Given this, we recommend that the IESG
Show full document text