rfc3238.txt

RFC 的详细文档！

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
   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                      [Page 2]

RFC 3238              IAB Considerations for OPES           January 2002


   the ability of end hosts to detect and respond to the inappropriate
   behavior of intermediaries could be applied to the architectures for
   web caches and content distribution infrastructures even without the
   additional complication of OPES.

   Each section of the document contains a set of IAB Considerations
   that we would recommend be addressed by the OPES architecture.
   Section 6 summarizes by listing all of these considerations in one
   place.

   In this document we try to use terminology consistent with RFC 3040
   [RFC 3040] and with OPES works in progress.

2.  Some history of the controversy about chartering OPES

   One view on OPES has been that "OPES is deeply evil and the IETF
   should stay far, far away from this hideous abomination" [ODell01].
   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 [CDT01].  This view of the
   risks of OPES was revised in later email, based on the proposals from
   [Carr01], "assuming that certain privacy and integrity protections
   can be incorporated into the goals of the working group" [Morris01].

   One issue concerns the one-party consent model.  In the one-party
   consent model, one of the end-nodes (that is, either the content
   provider or the end user) is required to explicitly authorize the
   OPES service, but authorization is not required from both parties.
   [CDT01] comments that relying only on a one-party consent model in
   the OPES charter "could facilitate third-party or state-sponsored
   censorship of Internet content without the knowledge or consent of
   end users", among other undesirable scenarios.

   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.  (Note that we are
   asking here whether there is architectural benefit, which is not the
   same as asking if there is a business model.)  Client-centric
   services suggested for OPES include virus scanning, language
   translation, limited client bandwidth adaptation, request filtering,
   and adaptation of streaming media, and suggested server-centric
   services include location-based services and personalized web pages.






IAB                          Informational                      [Page 3]

RFC 3238              IAB Considerations for OPES           January 2002


   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.

   A second question is 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.  This
   is similar to the issues considered in RFC 3135 [RFC 3135] of the
   relative costs and benefits of placing performance-enhancing proxies
   (PEPs) in the middle of a network to address link-related
   degradations.  In the case of PEPs, the potential costs include
   disabling the end-to-end use of IP layer security mechanisms;
   introducing a new possible point of failure that is not under the
   control of the end systems; adding increased difficulty in diagnosing
   and dealing with failures; and introducing possible complications
   with asymmetric routing or mobile hosts.  RFC 3135 carefully
   considers these possible costs, the mitigations that can be
   introduced, and the cases when the benefits of performance-enhancing
   proxies to the user are likely to outweigh the costs.  A similar
   approach could be applied to OPES services (though we do not attempt
   that here).

   A third question is whether an OPES service, designed primarily for a
   single retrieval action, has an impact on the application layer
   addressing architecture.  This is related to the integrity issue
   above, but is independent of whether these services are applied in
   the middle of the network or at either end.

   Most of this document deals with the specific issue of data integrity
   with OPES services, including the goal of enabling end hosts to
   detect and respond to inappropriate behavior from broken or
   compromised OPES intermediaries.

   We agree that 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, as we discuss in the next section of this document, we agree
   with [CDT01] that 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



IAB                          Informational                      [Page 4]

RFC 3238              IAB Considerations for OPES           January 2002


   [CDT01] 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.  Many of the protocols in the
   IETF could be modified for anti-social purposes - transport protocols
   could be modified to evade end-to-end congestion control, routing
   protocols could be modified to inject invalid routes, web proxy
   caches could be used for the unauthorized modification of content
   even without OPES, and so on.  None of these seem like compelling
   reasons not to standardize transport protocols, routing protocols,
   web caching protocols, or OPES itself.  In our view, it means instead
   that 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
   were authorized to modify content, but perform inappropriate
   modifications.  We would note that mechanisms can *help* end-users to
   detect compromised OPES intermediaries in some cases even if they do
   not *guarantee* that end-users will be able to detect compromised
   OPES intermediaries in all cases.

   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 end-to-end encryption by one or more ends
   of an OPES-involved session.  If OPES was compatible with end-to-end
   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 end-to-end 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.

   IAB Considerations:

   (2.1) One-party consent: 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).





IAB                          Informational                      [Page 5]

RFC 3238              IAB Considerations for OPES           January 2002


   (2.2) IP-layer communications: For an OPES framework standardized in
   the IETF, the OPES intermediary must be explicitly addressed at the
   IP layer by the end user.

   We note that (2.2) is not intended to preclude a chain of
   intermediaries, with the first intermediary in the chain explicitly
   addressed at the IP layer by the end user.

3.  End-to-end Integrity

   The proposed OPES services have several possible forms, including
   server-centric services, such as the dynamic assembling of web pages,
   explicitly authorized by the content provider; client-centric
   services such as virus scanning or language translation explicitly
   authorized by the end user to act on the response from the content
   provider; and client-centric services such as privacy-based services
   or content-filtering explicitly authorized by the end user to act on
   the request from the end user to the content provider.  We consider
   the issue of the end-to-end integrity of data separately for these
   different classes of services.

   For each specific service, the question arises of whether it is
   necessary for both the content provider and the end user to be able
   to detect and respond to inappropriate behavior by OPES
   intermediaries, or if it is sufficient for just one of the two end-
   hosts to have this ability.  We don't attempt a general answer, but
   we do discuss the issues further in the sections below.

3.1.  Data integrity with client-centric OPES services on responses

   Why is there any concern about the end-to-end integrity of data in a
   client-centric OPES service acting on a response from a content
   provider?  If the client requests a service such as virus scanning or