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 require that the OPES architecture protect end-to-end data integrity by supporting end-host detection and response to inappropriateShow full document text