RFC 3238 (rfc3238) - Page 2 of 17

IAB Architectural and Policy Considerations for Open Pluggable Edge Services

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 [RFC 2316].  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
   behavior by OPES intermediaries.  We note that in this case by
   "supporting end-host detection", we are referring to supporting
   detection by the humans responsible for the end hosts at the content
   provider and client.  We would note that many of these concerns about



IAB                          Informational