IAB Architectural and Policy Considerations for Open Pluggable Edge Services
RFC 3238

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

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 inappropriate