doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc3238.txt b/doc/rfc/rfc3238.txt
new file mode 100644
index 0000000..a45a265
--- /dev/null
+++ b/doc/rfc/rfc3238.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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
+   language translation, why is that of any concern to the content
+   provider one way or another?  One answer is that one of the proper
+   concerns of the IETF is to design architectures that enable end-hosts
+   to detect and respond to inappropriate actions in the network.  This
+   seems of particular importance for powerful devices in the network
+   such as OPES intermediaries, which are authorized by one of the end-
+   nodes to act on or transform data in the network, but other than that
+   are not under the direct control of that end-node.
+
+   Consider as an example the services of virus scanning or language
+   translation.  The end user has reasonable power in detecting and
+   dealing with imperfect or corrupted virus scanners or language
+   translators that are under her direct control (e.g., on her own
+   machine).  The end user knows exactly what program is installed, and
+   has direct access to the content before and after the service is
+
+
+
+IAB                          Informational                      [Page 6]
+
+RFC 3238              IAB Considerations for OPES           January 2002
+
+
+   applied.  The end user would have less control over similar services
+   offered by OPES in the network itself, where the end user's only
+   control might be the binary one of authorizing or not authorizing the
+   service.  (We also note that services deployed on the end host in a
+   self-contained fashion, such as a local virus scanning program, are
+   not a service in the network, and therefore are not in the province
+   of the IETF one way or another.)
+
+   For a OPES service such as virus scanning or language translation,
+   the end user could detect a corrupted intermediary, but only through
+   a "black-box" approach of comparing the input with the output.  This
+   is also imprecise and requires some effort, compared to the effort
+   required to detect a corrupted virus scanner installed on one's own
+   machine.  For example, the user could retrieve the "non-OPES" version
+   of the content directly from the content provider, if there is a
+   "non-OPES" version, and compare this with the "OPES" version of the
+   content available from the OPES intermediary.  However, in the case
+   of dynamic content, the "non-OPES" version of the content retrieved
+   by the user directly from the content provider might not necessarily
+   be the same as the "non-OPES" version of the content considered by
+   the OPES intermediary.  This limited control by the end user of the
+   OPES service, and the limited ability of the end user to detect
+   imperfect or corrupted intermediaries, argues for an architecture
+   that helps the content provider to detect and respond to imperfect or
+   corrupted OPES intermediaries as well.
+
+   We consider the specific example of virus scanning, authorized by the
+   end user as an OPES service.  One could imagine virus scanning as a
+   widely deployed OPES service, augmenting the virus scanning done on
+   the end host itself.  If I ask for, say, a paper by Steve Bellovin on
+   security and viruses in the network, and am informed by my authorized
+   OPES virus-scanning service that this content does not pass the
+   virus-scan, there are a number of possibilities:
+
+   (1) Unknown to Steve, the content (that is, Steve's paper) contains a
+       harmful virus.
+
+   (2) Steve inserted a harmful virus in the content on purpose, with
+       playful or malicious intent.
+
+   (3) The OPES virus scanner can't distinguish between a true harmful
+       virus, and Steve's paper about harmful viruses.
+
+   (4) My local OPES virus scanner has been hacked, with malicious
+       intent, to reject all content from Steve Bellovin.
+
+
+
+
+
+
+IAB                          Informational                      [Page 7]
+
+RFC 3238              IAB Considerations for OPES           January 2002
+
+
+   At some point, for some content, some widely-deployed implementation
+   of some OPES virus scanner is likely to result in problem (3), and
+   some OPES implementation is likely to be corrupted to result in
+   problem (4).  Because the end user has limited control over the OPES
+   virus scanner, the end user also is limited in its ability to detect
+   problems (3) or (4) in the OPES virus scanner.  In addition, the
+   content provider is probably the one with the strongest incentive to
+   detect problems (3) or (4) in the OPES virus scanner.  (The content
+   provider generally has a strong incentive to detect problem (1) as
+   well.)  In this case, it seems prudent that the overall OPES
+   architecture should be carefully designed to prevent the OPES service
+   of virus scanning, as authorized by the client, from unnecessarily
+   preventing the distribution of content that in fact does not have
+   viruses.
+
+   Obviously, it is not viable to propose that content providers simply
+   indicate that some content should be passed to the end user without
+   virus scanning - the point of virus scanning is for the end user to
+   exercise control in this regard.  However, if some form of end-system
+   notification allows the content provider to find out that the content
+   is being rejected by a virus scanning service instead of being
+   delivered to the end user, then the content provider (Steve, in this
+   case) might want to inform end users that this content is known by
+   the content provider not to pass some OPES virus scanning services.
+   End users could then make their own decisions about whether or not to
+   retrieve that content bypassing the OPES virus scanning service,
+   relying on their own virus scanner or an alternate virus scanning
+   service for this particular content.  Such end-system notification to
+   the content provider, if requested, cannot be enforced, and cannot be
+   relied upon from corrupted intermediaries, but it seems important
+   nevertheless.
+
+   Of course, malicious users can also use their awareness of the virus
+   scanning service to perfect their ability to construct malicious
+   viruses that can evade the virus scanning service.  This will be done
+   anyway, with any virus scanning service, and seems like an acceptable
+   cost to allow content providers some protection against the vagaries
+   of imperfect or corrupted OPES services in the network.
+
+   Thus, for client-requested services such as virus scanning and
+   language translation, it is clearly desirable for the origin server
+   to have notification, if it requests it, that these services are
+   being performed on its content before the content is sent to the
+   client.  Any such end-system notification might be accompanied by
+   reduced performance (in terms of overhead, delays, etc.) for the OPES
+   service applied to that content.  But some form of end-system
+
+
+
+
+
+IAB                          Informational                      [Page 8]
+
+RFC 3238              IAB Considerations for OPES           January 2002
+
+
+   notification is clearly necessary if content providers are to be able
+   to detect and respond to actions by OPES intermediaries that are
+   deemed inappropriate by the content provider.
+
+   Similarly for a client-based OPES service of language translation, it
+   is clearly desirable for content providers to be able to inform end
+   users when some content is deemed by the content provider to be
+   incompatible with language translation.  In this case, the important
+   issue is not to prevent the OPES language translation from being
+   performed on the content, but instead to give the content provider
+   some mechanism to discover the language translation, and to inform
+   the end user (or more precisely, to inform the end user's host
+   computer) if the content provider believes that this language
+   translation is incompatible with this particular content.
+
+   IAB Considerations:
+
+   (3.1) Notification: The overall OPES framework needs to assist
+   content providers in detecting and responding to client-centric
+   actions by OPES intermediaries that are deemed inappropriate by the
+   content provider.
+
+3.2.  Data integrity with server-centric OPES services
+
+   What are the concerns, if any, with the end-to-end integrity of data
+   in a server-centric OPES service such as location-based services?
+   For example, CNN could authorize a location-based OPES service, where
+   the OPES intermediary inserts the weather report or news headline of
+   regional interest into the requested web page.  The same issue of the
+   detection and response to broken or modified OPES intermediaries
+   occurs with server-centric OPES as with client-centric OPES services.
+   We only consider server-centric services on responses, as we are not
+   aware of any proposals for server-centric OPES services on requests
+   from the client to the content provider.
+
+   How are the end-nodes to detect inappropriate actions from OPES
+   services authorized by the content provider?  The OPES service is
+   being performed at an OPES intermediary in the network itself, and
+   not under the direct control of the content provider; in particular,
+   the content provider might not have the ability to monitor directly
+   the output of the OPES intermediary.  One could argue that the
+   content provider and server-centric OPES intermediary are part of a
+   single distributed application, and can be responsible on their own
+   for detecting and dealing with broken or modified OPES
+   intermediaries, without involving the end user.  But this is
+   unconvincing, basically arguing that standardizing protocols for
+   performing OPES services is a network issue properly in the domain of
+   the IETF, but the ensuring the overall integrity of the service is a
+
+
+
+IAB                          Informational                      [Page 9]
+
+RFC 3238              IAB Considerations for OPES           January 2002
+
+
+   distributed application matter, and not in the province of the IETF
+   at all.  It would seem to us that you can't have it both ways.
+   Simply labeling the content provider and the OPES intermediary as
+   part of the same distributed application does not give the content
+   provider the ability to monitor the actions of the OPES intermediary.
+
+   However, if the end user receives some form of notification that
+   these OPES services have been provided, and has some mechanism for
+   receiving the "non-OPES" content from the content provider without
+   the OPES intermediary's modifications (if there is such a thing as a
+   non-OPES version of the content), then the end user is in a better
+   position to detect and react to inappropriate actions from
+   compromised or poorly-designed OPES intermediaries.  Thus, it is
+   clear that some form of end-system notification is required to allow
+   the end user to detect and respond to broken or modified OPES
+   intermediaries.  If the end user has notification of action by OPES
+   intermediaries, it could "veto" an OPES service simply by throwing
+   the OPES-modified content away.  And if the client wants to talk
+   directly to the origin server to receive the "non-OPES" version, and
+   the origin server is configured to allow this, then the OPES
+   intermediary must be designed to permit this end-to-end
+   communication.
+
+   In addition to concerns about detecting and responding to faulty or
+   compromised OPES intermediaries, there are purely policy-based
+   concerns about the integrity of data.  If the content provider looks
+   at the source IP address from the HTTP request, or tosses a coin, in
+   order to decide what content to provide, then that is the content
+   provider's business.  But if there exists a "non-OPES" version of
+   some content available from the content provider, and also modified
+   versions available from OPES intermediaries, then it is important
+   that end users would be able to discover that they are receiving a
+   modified version from the network, and not the "non-OPES" version
+   that is also available from the content provider directly.
+
+   IAB Considerations:
+
+   (3.2) Notification: The overall OPES framework should assist end
+   users in detecting the behavior of OPES intermediaries, potentially
+   allowing them to identify imperfect or compromised intermediaries.
+
+   (3.3) Non-blocking: If there exists a "non-OPES" version of content
+   available from the content provider, the OPES architecture must not
+   prevent users from retrieving this "non-OPES" version from the
+   content provider.
+
+
+
+
+
+
+IAB                          Informational                     [Page 10]
+
+RFC 3238              IAB Considerations for OPES           January 2002
+
+
+3.3.  Data integrity with client-centric OPES services on requests
+
+   There have also been proposals for OPES services authorized by the
+   client on requests from the client to the content provider.  Examples
+   include services that remove fields from the HTTP header for added
+   privacy, and content-filtering services that filter requests based on
+   the requested URL.  For such services, there is still a need for end
+   hosts to be assisted in detecting and responding to imperfect or
+   corrupted intermediaries, but it seems less clear to what extent this
+   applies to the content provider, and to what extent it applies to the
+   end user that authorized the service.  The requirements will probably
+   have to be determined by the OPES and wider IETF communities on a
+   case-by-case basis for each specific service.
+
+4.  Application Layer Addresses
+
+   Most application layer addressing revolves around URIs, which, for
+   the most part, give a structured method to refer to a single data
+   entity on a remote server.  URIs are universal in that, in principle,
+   the same result is obtained irrespective of the location of the
+   client performing the resolution.
+
+   Practice often differs from this theory -- ad-strippers remove data
+   from pages at the client end; web server farms redirect clients to
+   one of several potential target machines for load-balancing or to
+   give the user "localized" content.
+
+   However, from an architectural standpoint, it is important to be
+   clear about what is being done here.  In all cases, URI resolution
+   standards (as defined for individual URI schemes, such as HTTP) apply
+   unchanged between the client and the OPES intermediary.  What the
+   intermediary does to fulfill the request is not material to the
+   discussion, and must produce a result that is compliant with the
+   applicable URI scheme definition.  In this sense, the OPES
+   intermediary is the "endpoint" of URI resolution.
+
+   In client-centric OPES, the intermediary is resolving the URI on
+   behalf of the client, and then applying client-requested services to
+   provide a data response to the client.  The client gets the data it
+   wanted, but it did not carry out the URI resolution.
+
+   In server-centric OPES, the "origin server" cedes its authority to
+   the intermediary to determine what is the "appropriate" content to
+   supply for a given URI.   The client may well perform standard URI
+   resolution, but that reaches no further than the intermediary.
+
+   With those distinctions firmly in mind, there are two particular
+   areas of concern for OPES-like services.
+
+
+
+IAB                          Informational                     [Page 11]
+
+RFC 3238              IAB Considerations for OPES           January 2002
+
+
+   The first is the consideration of the effect of a series of
+   interactions, over time and location (i.e., not just one document
+   retrieval).   Potential problems include inconsistencies in intra-
+   and inter-document references -- depending on what content is
+   changed, references from one version of a document might not exist in
+   a modified target, etc.
+
+   The other concern is whether this leads to the creation of content
+   that is exclusively accessible through the use of an intermediary.
+   That is, there is no "non-OPES" version.  Either this should not be
+   allowed, or this would argue for an extension to the Internet
+   application layer addressing architecture.
+
+   IAB Considerations:
+
+   (4.1) URI resolution: OPES documentation must be clear in describing
+   these services as being applied to the result of URI resolution, not
+   as URI resolution itself.
+
+   (4.2) Reference validity: All proposed services must define their
+   impact on inter- and intra-document reference validity.
+
+   (4.3) Any services that cannot be achieved while respecting the above
+   two considerations may be reviewed as potential requirements for
+   Internet application addressing architecture extensions, but must not
+   be undertaken as ad hoc fixes.
+
+5.  Privacy
+
+   Intermediaries in the middle of the network increase the number of
+   locations where the privacy of an end-to-end transaction could be
+   compromised.  Some of these privacy concerns apply to web caches and
+   CDNs in general as well as specifically to OPES intermediaries.  It
+   seems a reasonable requirement, for OPES to be chartered in the IETF,
+   that the issue of providing mechanisms for end users to determine the
+   privacy policies of OPES intermediaries should be addressed.  These
+   mechanisms could be quite different for client-centric and server-
+   centric OPES services.
+
+   For a complex issue such as an OPES architecture, which interacts
+   with protocols from other standards bodies as well as from other IETF
+   working groups, it seems necessary to keep in mind the overall
+   picture while, at the same time, breaking out specific parts of the
+   problem to be standardized in particular working groups.  Thus, a
+   requirement that the overall OPES architecture address privacy
+   concerns does not necessarily mean that the mechanisms for this need
+   to be developed in the IETF, or in the OPES working group (if it is
+   chartered).
+
+
+
+IAB                          Informational                     [Page 12]
+
+RFC 3238              IAB Considerations for OPES           January 2002
+
+
+   IAB Considerations:
+
+   (5.1) Privacy: The overall OPES framework must provide for mechanisms
+   for end users to determine the privacy policies of OPES
+   intermediaries.
+
+6.  Summary of 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).
+
+   (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.
+
+   (3.1) Notification: The overall OPES framework needs to assist
+   content providers in detecting and responding to client-centric
+   actions by OPES intermediaries that are deemed inappropriate by the
+   content provider.
+
+   (3.2) Notification: The overall OPES framework should assist end
+   users in detecting the behavior of OPES intermediaries, potentially
+   allowing them to identify imperfect or compromised intermediaries.
+
+   (3.3) Non-blocking: If there exists a "non-OPES" version of content
+   available from the content provider, the OPES architecture must not
+   prevent users from retrieving this "non-OPES" version from the
+   content provider.
+
+   (4.1) URI resolution: OPES documentation must be clear in describing
+   these services as being applied to the result of URI resolution, not
+   as URI resolution itself.
+
+   (4.2) Reference validity: All proposed services must define their
+   impact on inter- and intra-document reference validity.
+
+   (4.3) Any services that cannot be achieved while respecting the above
+   two considerations may be reviewed as potential requirements for
+   Internet application addressing architecture extensions, but must not
+   be undertaken as ad hoc fixes.
+
+   (5.1) Privacy: The overall OPES framework must provide for mechanisms
+   for end users to determine the privacy policies of OPES
+   intermediaries.
+
+
+
+
+
+IAB                          Informational                     [Page 13]
+
+RFC 3238              IAB Considerations for OPES           January 2002
+
+
+7.  Conclusions
+
+   This document includes comments and recommendations by the IAB on
+   some architectural and policy issues related to the chartering of
+   OPES in the IETF.
+
+8.  Acknowledgements
+
+   This document has benefited from discussions with members of the IAB
+   and the IESG, contributors to OPES, John Wroclawski, and others.
+   However, this is a document of the IAB, and we do not claim that the
+   other people listed above agree with the contents.
+
+9.  References
+
+   [Carr01]    Wayne Carr, "Suggested OPES Requirements for Integrity,
+               Privacy and Security", email to ietf-openproxy@imc.org,
+               August 16, 2001.  URL "http://www.imc.org/ietf-
+               openproxy/mail-archive/msg00869.html".
+
+   [CDT01]     Policy Concerns Raised by Proposed OPES Working Group
+               Efforts, email to the IESG, from the Center for Democracy
+               & Technology, August 3, 2001.  URL
+               "http://www.imc.org/ietf-openproxy/mail-
+               archive/msg00828.html".
+
+   [Clark88]   David D. Clark, The Design Philosophy of the DARPA
+               Internet Protocols, SIGCOMM 1988.
+
+   [Morris01]  John Morris, "Re: corrected -  Suggested OPES
+               Requirements for Integrity, Privacy and Security",
+               September 28, 2001.  Email to ietf-openproxy@imc.org, URL
+               "http://www.imc.org/ietf-openproxy/mail-
+               archive/msg00935.html".
+
+   [ODell01]   Mike O'Dell, "OPES continuing froth...", Message-Id:
+               <200107101341.JAA30276@ccr.org>, July 10, 2001, email to
+               ietf@ietf.org.  URL "http://www1.ietf.org/mail-
+               archive/ietf/Current/msg12650.html".
+
+   [OPES]      Open Pluggable Edge Services (OPES) Web Page,
+               "http://www.ietf-opes.org/".
+
+   [OPESBOF1]  OPES BOF, 49th IETF, December 12, 2000.  Agenda:
+               "http://www.ietf.org/ietf/00dec/opes-agenda.txt".
+               Minutes:  "http://www.ietf.cnri.reston.va.us/
+               proceedings/00dec/toc.htm#P25_256".
+
+
+
+
+IAB                          Informational                     [Page 14]
+
+RFC 3238              IAB Considerations for OPES           January 2002
+
+
+   [OPESBOF2]  OPES BOF, 50th IETF, March 9, 2001.  Minutes:
+               "http://www.ietf.org/proceedings/01mar/ietf50-40.htm".
+
+   [OPESBOF3]  OPES BOF, 51st IETF, August 2001.  Agenda:
+               "http://www.ietf.org/ietf/01aug/opes.txt".  Minutes:
+               "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM".
+
+   [Orman01]   Hilarie Orman, "Data Integrity for Open Pluggable
+               Services", email to ietf-openproxy@imc.org, August 15,
+               2001.  URL "http://www.imc.org/ietf-openproxy/mail-
+               archive/msg00865.html".
+
+   [RFC 2316]  Bellovin, S., "Report of the IAB Security Architecture
+               Workshop", RFC 2316, April 1998.
+
+   [RFC2401]   Kent, S. and R. Atkinson, "Security Architecture for the
+               Internet Protocol", RFC 2401, November 1998.
+
+   [RFC 3040]  Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
+               Replication and Caching Taxonomy", RFC 3040, January
+               2001.
+
+   [RFC 3135]  Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
+               Shelby, "Performance Enhancing Proxies Intended to
+               Mitigate Link-Related Degradations", RFC 3135, June 2001.
+
+   [Routson01] Joyce Routson, IETF's Edge Standards Controversy, July
+               11, 2001, Stardust CDN Week.  URL
+               "http://www.stardust.com/cdnweek/articles/2001/07/09/
+               opes.htm".
+
+10.  Security Considerations
+
+   This document does not propose any new protocols, and therefore does
+   not involve any security considerations in that sense.  However,
+   throughout this document there are discussions of the privacy and
+   integrity issues of OPES services and the architectural requirements
+   created by those issues.
+
+11.  IANA Considerations
+
+   There are no IANA considerations regarding this document.
+
+
+
+
+
+
+
+
+
+IAB                          Informational                     [Page 15]
+
+RFC 3238              IAB Considerations for OPES           January 2002
+
+
+Authors' Addresses
+
+   Internet Architecture Board
+   EMail:  iab@iab.org
+
+   Membership at time this document was completed:
+
+   Harald Alvestrand
+   Ran Atkinson
+   Rob Austein
+   Fred Baker
+   Steve Bellovin
+   Brian Carpenter
+   Jon Crowcroft
+   Leslie Daigle
+   Steve Deering
+   Sally Floyd
+   Geoff Huston
+   John Klensin
+   Henning Schulzrinne
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB                          Informational                     [Page 16]
+
+RFC 3238              IAB Considerations for OPES           January 2002
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB                          Informational                     [Page 17]
+