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 Rerved. 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 rvices
that would be deployed at application-level intermediaries in the
network, for example, at a web proxy cache between the origin rver and the client. The intermediaries would transform or filter
content, with the explicit connt of either the content provider or the end ur.
1. Introduction
Open Pluggable Edge Services (OPES) are rvices that would be
deployed in the network, for example, at a web proxy cache between
the origin rver and the client, that would transform or filter
content. Examples of propod OPES rvices include asmbling
personalized web pages, adding ur-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 raid
to the fore veral architectural and policy issues about robustness and the end-to-end integrity of data (in terms of the disparities
between what the "origin rver" makes available and what the client receives). In particular, questions have been raid about the
possible requirements, for a protocol to be developed and
IAB Informational [Page 1]
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 the issues.
The purpo 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, the 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 curity issues is to show that appropriate curity
mechanisms have been provided in the protocol, and another way to
address curity issues is to demonstrate that no curity issues
apply to this particular protocol. (Note however that a blanket
ntence that "no curity issues are involved" is never considered
sufficient to address curity concerns in a protocol with known
curity issues.)
This document will try to make our concerns underlying integrity,
privacy, and curity as clear as possible. We recommend that the
IESG require that OPES documents address integrity, privacy, and
curity concerns in one way or another, either directly by
demonstrating appropriate mechanisms, or by making a convincing ca that there are no integrity or privacy concerns relevant to a
particular document.
In particular, it ems unavoidable that at some point in the future some OPES rvice will perform inappropriately (e.g., a virus scanner rejecting content that does not include a virus), and some OPES
intermediary will be compromid either inadvertently or with
malicious intent. Given this, it ems 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 respon to inappropriate
behavior by OPES intermediaries. We note that in this ca 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 the concerns about IAB Informational [Page 2]
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 ction of the document contains a t of IAB Considerations
that we would recommend be addresd by the OPES architecture.
Section 6 summarizes by listing all of the considerations in one
place.
单身恋爱In this document we try to u 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 increa 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 revid in later email, bad 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 connt model. In the one-party
connt model, one of the end-nodes (that is, either the content
provider or the end ur) is required to explicitly authorize the
OPES rvice, but authorization is not required from both parties.
[CDT01] comments that relying only on a one-party connt model in
the OPES charter "could facilitate third-party or state-sponsored
censorship of Internet content without the knowledge or connt of
end urs", among other undesirable scenarios.
A natural first question is whether there is any architectural
benefit to putting specific rvices inside the network (e.g., at the application-level web cache) instead of positioning all rvices
either at the content provider or the end ur. (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
rvices suggested for OPES include virus scanning, language
translation, limited client bandwidth adaptation, request filtering, and adaptation of streaming media, and suggested rver-centric
rvices include location-bad rvices and personalized web pages. IAB Informational [Page 3]
It ems clear that there can indeed be significant architectural
benefit in providing some OPES rvices 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
ur requires some transformation (such as adaptation to a limited-
bandwidth path) applied to that data, providing that rvice at the
web cache itlf 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 rvice to the end ur.
A cond question is whether the architectural benefits of providing rvices 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 ca of PEPs, the potential costs include
disabling the end-to-end u of IP layer curity mechanisms;
introducing a new possible point of failure that is not under the
control of the end systems; adding incread difficulty in diagnosing and dealing with failures; and introducing possible complications
with asymmetric routing or mobile hosts. RFC 3135 carefully
considers the possible costs, the mitigations that can be
introduced, and the cas when the benefits of performance-enhancing proxies to the ur are likely to outweigh the costs. A similar
approach could be applied to OPES rvices (though we do not attempt that here).
A third question is whether an OPES rvice, 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 the rvices 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 rvices, including the goal of enabling end hosts to
detect and respond to inappropriate behavior from broken or狗肉炖豆腐
compromid OPES intermediaries.
We agree that one-party connt, with one of the end-hosts explicitly authorizing the OPES rvice, must be a requirement for OPES to be
standardized in the IETF.
However, as we discuss in the next ction of this document, we agree with [CDT01] that the one-party connt model by itlf (e.g., with
one of the end-hosts authorizing the OPES rvice, and the other
end-host perhaps being unaware of the OPES rvice) is insufficient
for protecting data integrity in the network. We also agree with
IAB Informational [Page 4]
[CDT01] that, regardless of the curity and authorization mechanisms standardized for OPES in the IETF, OPES implementations could
probably be modified to circumvent the mechanisms, resulting in the unauthorized modification of content. Many of the protocols in the
我的家人用英语怎么说
IETF could be modified for anti-social purpos - 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 ud for the unauthorized modification of content
even without OPES, and so on. None of the em like compelling
reasons not to standardize transport protocols, routing protocols,
web caching protocols, or OPES itlf. In our view, it means instead that the infrastructure needs, as much as possible, to be designed to detect and defend itlf against compromid implementations, and
misus of protocols need to be addresd directly, each in the
appropriate venue.
Mechanisms such as digital signatures, which help urs to verify for themlves 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 ca of OPES, additional protection to ensure the end-to-end integrity of data is desirable as well, for
example, to help end-urs to detect cas where OPES intermediaries were authorized to modify content, but perform inappropriate
modifications. We would note that mechanisms can *help* end-urs to detect compromid OPES intermediaries in some cas even if they do not *guarantee* that end-urs will be able to
惊讶拼音detect compromid
OPES intermediaries in all cas.
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 u of end-to-end encryption by one or more ends of an OPES-involved ssion. 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 addresd 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
t of rvices 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 connt: An OPES framework standardized in the IETF
殷光栋must require that the u of any OPES rvice be explicitly
authorized by one of the application-layer end-hosts (that is, either the content provider or the client).
IAB Informational [Page 5]
(2.2) IP-layer communications: For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addresd at the
IP layer by the end ur.
We note that (2.2) is not intended to preclude a chain of
intermediaries, with the first intermediary in the chain explicitly
addresd at the IP layer by the end ur.
3. End-to-end Integrity
The propod OPES rvices have veral possible forms, including
rver-centric rvices, such as the dynamic asmbling of web pages, explicitly authorized by the content provider; client-centric
rvices such as virus scanning or language translation explicitly
authorized by the end ur to act on the respon from the content
provider; and client-centric rvices such as privacy-bad rvices or content-filtering explicitly authorized by the end ur to act on the request from the end ur to the content provider. We consider
the issue of the end-to-end integrity of data parately for the
different class of rvices.
For each specific rvice, the question aris of whether it is
necessary for both the content provider and the end ur 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 ctions below.
3.1. Data integrity with client-centric OPES rvices on respons
Why is there any concern about the end-to-end integrity of data in a client-centric OPES rvice acting on a respon from a content
provider? If the client requests a rvice 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 ina
ppropriate actions in the network. This ems 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 rvices of virus scanning or language
translation. The end ur 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 ur knows exactly what program is installed, and has direct access to the content before and after the rvice is
IAB Informational [Page 6]
