draft-ietf-opes-iab-02.txt   draft-ietf-opes-iab-03.txt 
Open Pluggable Edge Services A. Barbir Open Pluggable Edge Services A. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: March 23, 2004 A. Rousskov Expires: April 26, 2004 A. Rousskov
The Measurement Factory The Measurement Factory
September 23, 2003 October 27, 2003
OPES Treatment of IAB Considerations OPES Treatment of IAB Considerations
draft-ietf-opes-iab-02 draft-ietf-opes-iab-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 23, 2004. This Internet-Draft will expire on April 26, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
IETF Internet Architecture Board (IAB) expressed nine IETF Internet Architecture Board (IAB) expressed nine
architecture-level considerations when Open Pluggable Edge Services architecture-level considerations for the Open Pluggable Edge
(OPES) working group was being chartered at the IETF. The working Services (OPES) framework. This document describes how OPES
group was chartered under the condition that IAB considerations were addresses those considerations.
addressed by the group. This document describes how OPES addresses
those considerations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Consideration (2.1) One-party consent . . . . . . . . . . . . 5 3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 5
4. Consideration (2.2) IP-layer communications . . . . . . . . . 6 4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 6
5. Notification Considerations . . . . . . . . . . . . . . . . . 8 5. Notification Considerations . . . . . . . . . . . . . . . . . 8
5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8 5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8
5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9 5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9
5.3 Consideration (3.1) Notification . . . . . . . . . . . . . . . 10 5.3 Consideration (3.1) 'Notification' . . . . . . . . . . . . . . 10
5.4 Consideration (3.2) Notification . . . . . . . . . . . . . . . 12 5.4 Consideration (3.2) 'Notification' . . . . . . . . . . . . . . 12
6. Consideration (3.3) Non-blocking . . . . . . . . . . . . . . . 13 6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 13
7. Consideration (4.1) URI resolution . . . . . . . . . . . . . . 14 7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 14
8. Consideration (4.2) Reference validity . . . . . . . . . . . . 15 8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 15
9. Consideration (4.3) Addressing extensions . . . . . . . . . . 16 9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 16
10. Consideration (5.1) Privacy . . . . . . . . . . . . . . . . . 17 10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 18
12. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19
13. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Normative References . . . . . . . . . . . . . . . . . . . . . 23 Normative References . . . . . . . . . . . . . . . . . . . . . 23
Informative References . . . . . . . . . . . . . . . . . . . . 24 Informative References . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . 25
1. Introduction 1. Introduction
The Open Pluggable Edge Services (OPES) architecture The Open Pluggable Edge Services (OPES) architecture
[I-D.ietf-opes-architecture], enables cooperative application [I-D.ietf-opes-architecture], enables cooperative application
services (OPES services) between a data provider, a data consumer, services (OPES services) between a data provider, a data consumer,
and zero or more OPES processors. The application services under and zero or more OPES processors. The application services under
consideration analyze and possibly transform application-level consideration analyze and possibly transform application-level
messages exchanged between the data provider and the data consumer. messages exchanged between the data provider and the data consumer.
In the process of chartering OPES, the IAB made recommendations on In the process of chartering OPES, the IAB made recommendations on
issues that OPES solutions should be required to address. These issues that OPES solutions should be required to address. These
recommendations were formulated in the form of specific IAB recommendations were formulated in the form of a specific IAB
considerations [RFC3238]. IAB emphasized that its considerations did considerations document [RFC3238]. In that document, IAB emphasized
not recommend specific solutions and did not mandate specific that its considerations did not recommend specific solutions and did
functional requirements. Addressing an IAB consideration may involve not mandate specific functional requirements. Addressing an IAB
showing appropriate protocol mechanisms or demonstrating that the consideration may involve showing appropriate protocol mechanisms or
issue does not apply. Addressing a consideration does not necessarily demonstrating that the issue does not apply. Addressing a
mean supporting technology implied by the consideration wording. consideration does not necessarily mean supporting technology implied
by the consideration wording.
The primary goal of this document is to show that all IAB The primary goal of this document is to show that all IAB
considerations are addressed by OPES, to the extent those recommendations are addressed by OPES, to the extent that those
considerations can be addressed by an IETF working group. Limitations considerations can be addressed by an IETF working group. The
of OPES working group ability to address certain aspects of IAB limitations of OPES working group to address certain aspects of IAB
considerations are explicitly documented. considerations are also explicitly documented.
There are nine IAB considerations [RFC3238] that OPES has to address. There are nine IAB considerations [RFC3238] that OPES has to address.
In the core of this document are the corresponding nine In the core of this document are the corresponding nine
"Consideration" sections. For each IAB consideration, its section "Consideration" sections. For each IAB consideration, its section
contains general discussion as well as references to specific OPES contains general discussion as well as references to specific OPES
mechanisms relevant to the consideration. mechanisms relevant to the consideration.
2. Terminology 2. Terminology
This document does not introduce any new terminology but uses This document does not introduce any new terminology but uses
terminology from other OPES documents it quotes. terminology from other OPES documents it quotes.
3. Consideration (2.1) One-party consent 3. Consideration (2.1) 'One-party consent'
"An OPES framework standardized in the IETF must require that the use "An OPES framework standardized in the IETF must require that the use
of any OPES service be explicitly authorized by one of the of any OPES service be explicitly authorized by one of the
application-layer end-hosts (that is, either the content provider or application-layer end-hosts (that is, either the content provider or
the client)."[RFC3238] the client)."[RFC3238]
OPES architecture requires that "OPES processors MUST be consented to OPES architecture requires that "OPES processors MUST be consented to
by either the data consumer or data provider application" by either the data consumer or data provider application"
[I-D.ietf-opes-architecture]. This requirement alone cannot prevent [I-D.ietf-opes-architecture]. This requirement alone cannot prevent
consent-less introduction of OPES processors. In consent-less introduction of OPES processors. In
[I-D.ietf-opes-end-comm], the OPES architecture enables concerned [I-D.ietf-opes-end-comm], the OPES architecture enables concerned
parties to detect unwanted OPES processors by examining OPES traces. parties to detect unwanted OPES processors by examining OPES traces.
The use of traces in OPES is mandatory. The use of traces in OPES is mandatory.
Tracing mechanism on its own is unable to detect processors that are A tracing mechanism on its own cannot detect processors that are in
in violation of OPES specifications. Examples include OPES processors violation of OPES specifications. Examples include OPES processors
operating in stealth mode. However, the OPES architecture allows the operating in stealth mode. However, the OPES architecture allows the
use of content signature to verify the authenticity of performed use of content signature to verify the authenticity of performed
adaptations. Content signatures is a strong but expensive mechanism adaptations. Content signatures is a strong but expensive mechanism
that can detect any modifications of signed content provided the that can detect any modifications of signed content provided that the
content provider is willing to sign the data and the client is content provider is willing to sign the data and that the client is
willing to either check the signature or relay received content to willing to either check the signature or relay received content to
content provider for signature verification. the content provider for signature verification.
OPES adaptations may include copying and other forms of non-modifying OPES adaptations may include copying and other forms of non-modifying
access to content. These kinds of adaptations cannot be detected by access to content. These kinds of adaptations cannot be detected by
the above mentioned mechanisms. Thus, "passive" OPES processors can the above mentioned mechanisms. Thus, "passive" OPES processors can
operate without consent. If presence of such processors is a concern, operate on the content without the data consumer or provider consent.
content encryption can be used. A passive processor is no different If presence of such processors is a concern, then content encryption
from a proxy or intermediary operating outside of OPES framework. No can be used. A passive processor is no different from a proxy or an
OPES mechanism can prevent non-modifying access to content. intermediary operating outside of OPES framework. No OPES mechanism
(existing or foreseeable) can prevent non-modifying access to
content.
4. Consideration (2.2) IP-layer communications 4. Consideration (2.2) 'IP-layer communications'
"For an OPES framework standardized in the IETF, the OPES "For an OPES framework standardized in the IETF, the OPES
intermediary must be explicitly addressed at the IP layer by the end intermediary must be explicitly addressed at the IP layer by the end
user."[RFC3238] user."[RFC3238]
OPES architecture requires that "OPES processors MUST be addressable The OPES architecture requires that "OPES processors MUST be
at the IP layer by the end user (data consumer application)" addressable at the IP layer by the end user (data consumer
[I-D.ietf-opes-architecture]. IAB and the architecture draft mention application)" [I-D.ietf-opes-architecture]. The IAB and the
an important exception: addressing the first OPES processor in a architecture documents mention an important exception: addressing the
chain of processors is sufficient. That is, a chain of OPES first OPES processor in a chain of processors is sufficient. That is,
processors is viewed as a single OPES "system" at the address of the a chain of OPES processors is viewed as a single OPES "system" at the
first chain element. address of the first chain element.
The notion of a chain is not strictly defined by IAB. For the purpose The notion of a chain is not strictly defined by IAB. For the purpose
of addressing this consideration, we consider a group of OPES of addressing this consideration, a group of OPES processors working
processors working on a given application transaction. Such a group on a given application transaction is considered. Such a group would
would necessarily form a single processing chain, with a single necessarily form a single processing chain, with a single "exit" OPES
"exit" OPES processor (the processor that adapted the given message processor (i.e., the processor that adapted the given message last).
last). OPES architecture essentially requires that last OPES The OPES architecture essentially requires that last OPES processor
processor to be explicitly addressable at the IP layer by the end to be explicitly addressable at the IP layer by the data consumer
user. Note that chain formation, including its exit point may depend application. The chain formation, including its exit point may depend
on an application message and other dynamic factors such as time of on an application message and other dynamic factors such as time of
day or system load. the day or system load.
Furthermore, if OPES processing is an internal processing step at Furthermore, if OPES processing is an internal processing step at a
data consumer or provider side, then the last OPES processor may data consumer or a data provider application side, then the last OPES
reside in a private address space of the side's network and may not processor may reside in a private address space and may not be
be explicitly addressable. In such situations, the processing side explicitly addressable from the outside. In such situations, the
must designate an addressable point on the same processing chain. processing side must designate an addressable point on the same
That designated point may not be, strictly speaking, an OPES processing chain. That designated point may not be, strictly
processor, but it will suffice as such as far as IAB considerations speaking, an OPES processor, but it will suffice as such as far as
are concerned -- the other side will be able to address it explicitly IAB considerations are concerned -- the data consumer application
at the IP layer and it will represent the OPES processing chain to will be able to address it explicitly at the IP layer and it will
the outside world. represent the OPES processing chain to the outside world.
Designating an addressable processing point avoids the conflict Designating an addressable processing point avoids the conflict
between narrow interpretation of IAB consideration and real system between narrow interpretation of the IAB consideration and real
designs: It is irrational to expect a content provider to provide system designs. It is irrational to expect a content provider to
access to internal hosts participating in content generation, whether provide access to internal hosts participating in content generation,
OPES processors are involved or not. Moreover, providing such access whether OPES processors are involved or not. Moreover, providing such
would serve little practical purpose because internal OPES processors access would serve little practical purpose because internal OPES
are not likely to be able to answer any end user queries, being processors are not likely to be able to answer any data consumer
completely out of content generation context. For example, an OPES queries, being completely out of content generation context. For
processor adding customer-specific information to XML pages may not example, an OPES processor adding customer-specific information to
understand or be aware of any final HTML content that the end user XML pages may not understand or be aware of any final HTML content
receives and may not be able to map end user request to any internal that the data consumer application receives and may not be able to
user identification. Since OPES requires the end of the message map end user request to any internal user identification. Since OPES
processing chain to be addressable, the conflict does not exist -- requires the end of the message processing chain to be addressable,
OPES places no requirements on the internal architecture of data the conflict does not exist. OPES places no requirements on the
producer systems while requiring the entire OPES-related content internal architecture of data producer systems while requiring the
production "system" to be addressable at the IP layer. entire OPES-related content production "system" to be addressable at
the IP layer.
Public/Private Domain | Private Domain Private Domain | Public Domain | Private Domain
| | |
+--------------+ | +------+ +--------------+ | +-------------+ +--------+
| Data | *-------* +----------+ | | OPES | | Data | | | OPES System | |Data |
| Consumer |<-->/ Network \<-->| Public IP| | +------+ | Consumer |<--- network -->| with public |<---->|Provider|
| Application | \(Public) / | Address |<-->| . | Application | | | IP address | |App |
+--------------+ *-------* | OPES | | . +--------------+ | +-------------+ +--------+
+----------+ | . | |
| +------+ | |
| | OPES |
| +------+
|
Figure 1 Figure 1
(XXX: should we add a picture showing internal and external OPES
intermediaries? more pictures showing other OPES layouts? Move to
architecture draft?)
5. Notification Considerations 5. Notification Considerations
This section discusses how OPES framework addresses IAB Notification This section discusses how OPES framework addresses IAB Notification
considerations 3.1 and 3.2. considerations 3.1 and 3.2.
5.1 Notification versus trace 5.1 Notification versus trace
Before specific considerations are discussed, the relationship Before specific considerations are discussed, the relationship
between IAB notifications and OPES tracing has to be explained. OPES between IAB notifications and OPES tracing has to be explained. OPES
framework concentrates on tracing rather than notification. The framework concentrates on tracing rather than notification. The OPES
tracing specification [I-D.ietf-opes-end-comm] defines "OPES trace" Communications specification [I-D.ietf-opes-end-comm] defines "OPES
as "application message information about OPES entities that adapted trace" as information about OPES adaptations that is embedded in an
that message" and "OPES tracing" as "the process of including, application message. Thus, OPES trace follows the application message
manipulating, and interpreting an OPES trace" (XXX: keep these in it traces. The trace is for the recipient of the application message.
sync). Thus, OPES trace follows the application message it traces. Traces are implemented as extensions of application protocols being
The trace is for the recipient of the application message. Traces are adapted and traced.
implemented as extensions of application protocols being adapted and
traced.
As opposed to an OPES trace, provider notification (as implied by As opposed to an OPES trace, provider notification (as implied by
IAB) notifies the sender of the application message rather than the IAB) notifies the sender of the application message rather than the
recipient. Thus, notifications propagate in the opposite direction of recipient. Thus, notifications propagate in the opposite direction of
traces. Supporting notifications directly would require a new traces. Supporting notifications directly would require a new
protocol. Figure XXX illustrates the differences between a trace and protocol. Figure 2 illustrates the differences between a trace and
notification from a single application message point of view. notification from a single application message point of view.
sender --[message A]--> OPES --[message A']--> recipient
sender --[message A]---> OPES --[message A' + trace]--> recipient ^ V [with trace]
^ V
| | | |
+-<-- [notification] ---+ +-<-- [notification] ---+
Figure 2 Figure 2
Since notifications cannot be piggy-backed to application messages, Since notifications cannot be piggy-backed to application messages,
they create new messages and may at least double the number of they create new messages and may double the number of messages the
messages the sender has to process (more if several intermediaries on sender has to process. The number of messages that need to be proceed
the message path emit notifications). Moreover, associating is larger if several intermediaries on the message path generate
notifications with application messages may require duplicating notifications). Associating notifications with application messages
application message information in notifications and/or maintaining a may require duplicating application message information in
sender state until notification is received, increasing performance notifications and may require maintaining a sender state until
overhead of notifications. These concerns call for optional notification is received. These actions increase the performance
notification, with a special protocol to enable notifications when overhead of notifications.
needed.
The level of available details in notifications versus provider The level of available details in notifications versus provider
interest in supporting notification is another concern. Experience interest in supporting notification is another concern. Experience
shows that content providers often require very detailed information shows that content providers often require very detailed information
about user actions to be interested in notifications at all. For about user actions to be interested in notifications at all. For
example, Hit Metering protocol [XXX] has been designed to supply example, Hit Metering protocol [RFC2227] has been designed to supply
content providers with proxy cache hit counts, in an effort to reduce content providers with proxy cache hit counts, in an effort to reduce
cache busting behavior which was caused by content providers desire cache busting behavior which was caused by content providers desire
to get accurate site "access counts". However, the Hit Metering to get accurate site "access counts". However, the Hit Metering
protocol is currently not widely deployed because the protocol does protocol is currently not widely deployed because the protocol does
not supply content providers with information such as client IP not supply content providers with information such as client IP
addresses, browser versions, or cookies. addresses, browser versions, or cookies.
Hit Metering experience is relevant because Hit Metering protocol was Hit Metering experience is relevant because Hit Metering protocol was
designed to do for HTTP caching intermediaries what OPES designed to do for HTTP caching intermediaries what OPES
notifications are meant to do for OPES intermediaries. Performance notifications are meant to do for OPES intermediaries. Performance
requirements call for state reduction via aggregation of requirements call for state reduction via aggregation of
notifications while provider preferences call for state preservation notifications while provider preferences call for state preservation
or duplication. Achieving the right balance when two sides belong to or duplication. Achieving the right balance when two sides belong to
different organizations and have different optimization priorities different organizations and have different optimization priorities
may be impossible. may be impossible.
Thus, instead of explicitly supporting notifications on a protocol Thus, instead of explicitly supporting notifications at the protocol
level, OPES concentrates on tracing facilities and supports level, OPES concentrates on tracing facilities. In essence, OPES
notifications indirectly, using those tracing facilities. In other supports notifications indirectly, using tracing facilities. In other
words, the IAB choice of "Notification" label is interpreted as words, the IAB choice of "Notification" label is interpreted as
"Notification assistance" (i.e. making notifications meaningful) and "Notification assistance" (i.e. making notifications meaningful) and
is not interpreted as a "Notification protocol". is not interpreted as a "Notification protocol".
Nevertheless, OPES architecture allows for an efficient and The above concerns call for making notification optional. The OPES
meaningful notification protocol to be implemented in certain OPES architecture allows for an efficient and meaningful notification
environments. For specific examples, see the "Optional Notification" protocol to be implemented in certain OPES environments. For
section in [I-D.ietf-opes-end-comm]. specific examples, see the "Optional Notification" section in
[I-D.ietf-opes-end-comm].
5.2 An example of an OPES trace for HTTP 5.2 An example of an OPES trace for HTTP
The example below illustrates adaptations done to HTTP request at an The example below illustrates adaptations done to HTTP request at an
OPES intermediary operated by the client ISP. Both original (as sent OPES processor operated by the client ISP. Both original (as sent by
by an end user) and adapted (as received by the origin web server) an end user) and adapted (as received by the origin web server)
requests are shown. The primary adaptation is the modification of requests are shown. The primary adaptation is the modification of
HTTP "Accept" header. The secondary adaptation is the addition of an HTTP "Accept" header. The secondary adaptation is the addition of an
"OPES-Via" HTTP extension header. "OPES-Via" HTTP extension header [I-D.ietf-opes-http] (XXX: but it is
not OPES-Via, it is OPES-System for now; OPES-Via is probably better
for a few reasons though).
GET /pub/WWW/ HTTP/1.1 GET /pub/WWW/ HTTP/1.1
Host: www.w3.org Host: www.w3.org
Accept: text/plain Accept: text/plain
Figure 3 Figure 3
... may be adapted by an ISP OPES system to become: ... may be adapted by an ISP OPES system to become:
GET /pub/WWW/ HTTP/1.1 GET /pub/WWW/ HTTP/1.1
skipping to change at page 10, line 41 skipping to change at page 10, line 40
AVAILABLE DOCUMENTA... AVAILABLE DOCUMENTA...
Figure 6 Figure 6
In the above examples, "OPES-Via" header values contain URLs that may In the above examples, "OPES-Via" header values contain URLs that may
point to OPES-specific documents such as description of the OPES point to OPES-specific documents such as description of the OPES
operator and its privacy policy. Those documents may be operator and its privacy policy. Those documents may be
parameterized to allow for customizations specific to the transaction parameterized to allow for customizations specific to the transaction
being traced (e.g., client or even transaction identifier may be used being traced (e.g., client or even transaction identifier may be used
to provide more information about performed adaptations). Traced OPES to provide more information about performed adaptations). Traced OPES
URLs may be later used to request OPES bypass. (XXX: OPES specs will URLs may be later used to request OPES bypass
need to define OPES-Via format and semantics) [I-D.ietf-opes-end-comm].
5.3 Consideration (3.1) Notification 5.3 Consideration (3.1) 'Notification'
"The overall OPES framework needs to assist content providers in "The overall OPES framework needs to assist content providers in
detecting and responding to client-centric actions by OPES detecting and responding to client-centric actions by OPES
intermediaries that are deemed inappropriate by the content intermediaries that are deemed inappropriate by the content
provider."[RFC3238] provider."[RFC3238]
OPES tracing mechanisms assist content providers in detecting OPES tracing mechanisms assist content providers in detecting
client-centric actions by OPES intermediaries. Specifically, a client-centric actions by OPES intermediaries. Specifically, a
compliant OPES intermediary or system notifies a content provider of compliant OPES intermediary or system notifies a content provider of
its presence by including its tracing information in the application its presence by including its tracing information in the application
protocol requests. An OPES system MUST leave its trace (XXX quote protocol requests. An OPES system MUST leave its trace
tracing draft) [I-D.ietf-opes-end-comm]. Detection assistance has [I-D.ietf-opes-end-comm]. Detection assistance has its limitations.
its limitations. Some OPES intermediaries may work exclusively on Some OPES intermediaries may work exclusively on responses and may
responses and may not have a chance to trace the request. Moreover, not have a chance to trace the request. Moreover, some application
some application protocols may not have explicit requests (e.g., a protocols may not have explicit requests (e.g., a content push
content push service). service).
OPES tracing mechanisms assist content providers in responding to OPES tracing mechanisms assist content providers in responding to
client-centric actions by OPES intermediaries. Specifically, OPES client-centric actions by OPES intermediaries. Specifically, OPES
traces MUST include identification of OPES systems and SHOULD include traces MUST include identification of OPES systems and SHOULD include
a list of adaptation actions performed on provider's content. This a list of adaptation actions performed on provider's content. This
tracing information may be included in the application request. tracing information may be included in the application request.
Usually, however, this information will be included in the Usually, however, this information will be included in the
application response, an adapted version of which does not reach the application response, an adapted version of which does not reach the
content provider. If OPES end points cooperate, then notification can content provider. If OPES end points cooperate, then notification can
be assisted with traces. Content providers that suspect or experience be assisted with traces. Content providers that suspect or experience
difficulties can do any of the following: difficulties can do any of the following:
Check whether requests they receive pass through OPES o Check whether requests they receive pass through OPES
intermediaries. Presence of OPES tracing info will determine that. intermediaries. Presence of OPES tracing info will determine that.
This check is only possible for request/response protocols. For This check is only possible for request/response protocols. For
other protocols (e.g., broadcast or push), the provider would have other protocols (e.g., broadcast or push), the provider would have
to assume that OPES intermediaries are involved until proven to assume that OPES intermediaries are involved until proven
otherwise. otherwise.
If OPES intermediaries are suspected, request OPES traces from o If OPES intermediaries are suspected, request OPES traces from
potentially affected user(s). The trace will be a part of the potentially affected user(s). The trace will be a part of the
application message received by the user software. If users application message received by the user software. If involved
cooperate, the provider(s) have all the information they need. If parties cooperate, the provider(s) may have access to all the
users do not cooperate, the provider(s) cannot do much about it needed information. Certainly, lack of cooperation may hinder
(they might be able to deny service to uncooperative users in some access to tracing information. To encourage cooperation, data
cases). providers might be able to deny service to uncooperative users.
Some traces may indicate that more information is available by o Some traces may indicate that more information is available by
accessing certain resources on the specified OPES intermediary or accessing certain resources on the specified OPES intermediary or
elsewhere. Content providers may query for more information in elsewhere. Content providers may query for more information in
that case. this case.
If everything else fails, providers can enforce no-adaptation o If everything else fails, providers can enforce no-adaptation
policy using appropriate OPES bypass mechanisms and/or end-to-end policy using appropriate OPES bypass mechanisms and/or end-to-end
encryption mechanisms. encryption mechanisms.
OPES detection and response assistance is limited to application OPES detection and response assistance is limited to application
protocols with support for tracing extensions. For example, HTTP protocols with support for tracing extensions. For example, HTTP
[RFC2616] has such support while DNS over UDP does not. [RFC2616] has such support while DNS over UDP does not.
(XXX: should we prohibit adaptation of application protocols that do 5.4 Consideration (3.2) 'Notification'
not allow for tracing?)
5.4 Consideration (3.2) Notification
"The overall OPES framework should assist end users in detecting the "The overall OPES framework should assist end users in detecting the
behavior of OPES intermediaries, potentially allowing them to behavior of OPES intermediaries, potentially allowing them to
identify imperfect or compromised intermediaries."[RFC3238] identify imperfect or compromised intermediaries."[RFC3238]
OPES tracing mechanisms assist end users in detecting OPES OPES tracing mechanisms assist end users in detecting OPES
intermediaries. Specifically, a compliant OPES intermediary or system intermediaries. Specifically, a compliant OPES intermediary or system
notifies an end user of its presence by including its tracing notifies an end user of its presence by including its tracing
information in the application protocol messages sent to the client. information in the application protocol messages sent to the client.
An OPES intermediary MUST leave its trace (XXX quote tracing draft) An OPES system MUST leave its trace [I-D.ietf-opes-end-comm].
[I-D.ietf-opes-end-comm]. Detection assistance has its limitations. However, detection assistance has its limitations. Some OPES systems
Some OPES intermediaries may work exclusively on requests and may not may work exclusively on requests and may not have a chance to trace
have a chance to trace the response. Moreover, some application the response. Moreover, some application protocols may not have
protocols may not have explicit responses (e.g., event logging explicit responses (e.g., event logging service).
service).
OPES detection assistance is limited to application protocols with OPES detection assistance is limited to application protocols with
support for tracing extensions. For example, HTTP [RFC2616] has such support for tracing extensions. For example, HTTP [RFC2616] has such
support while DNS over UDP does not. support while DNS over UDP does not.
(XXX: should we prohibit adaptation of application protocols that do 6. Consideration (3.3) 'Non-blocking'
not allow for tracing?)
6. Consideration (3.3) Non-blocking
"If there exists a "non-OPES" version of content available from the "If there exists a "non-OPES" version of content available from the
content provider, the OPES architecture must not prevent users from content provider, the OPES architecture must not prevent users from
retrieving this "non-OPES" version from the content retrieving this "non-OPES" version from the content
provider."[RFC3238] provider."[RFC3238]
OPES intermediaries MUST support a bypass feature (XXX quote bypass "OPES entities MUST support a bypass feature"
draft) [I-D.ietf-opes-end-comm]. If an application message includes [I-D.ietf-opes-end-comm]. If an application message includes bypass
bypass instructions and an OPES intermediary is not configured to instructions and an OPES intermediary is not configured to ignore
ignore them, the matching OPES intermediary will not process the them, the matching OPES intermediary will not process the message. An
message. An intermediary may be configured to ignore bypass OPES intermediary may be configured to ignore bypass instructions
instructions only if no non-OPES version of content is available. only if no non-OPES version of content is available. Bypass may
Bypass may generate content errors since some OPES services may be generate content errors since some OPES services may be essential but
essential but may not be configured as such. may not be configured as such.
Bypass support has limitations similar to the two Bypass support has limitations similar to the two
notification-related considerations above. (XXX: but it is possible notification-related considerations above.
to instruct all OPES intermediaries to bypass an application message
without knowing all OPES intermediaries IDs).
(XXX: Ideally, this section need to be polished further -- if there
is no non-OPES version of the content, most IAB considerations
probably do not apply because there is really no adaptation, only
creation of content; and we should not restrict content creation.)
7. Consideration (4.1) URI resolution 7. Consideration (4.1) 'URI resolution'
"OPES documentation must be clear in describing these services as "OPES documentation must be clear in describing these services as
being applied to the result of URI resolution, not as URI resolution being applied to the result of URI resolution, not as URI resolution
itself."[RFC3238] itself."[RFC3238]
"OPES Scenarios and Use Cases" specification "OPES Scenarios and Use Cases" specification
[I-D.ietf-opes-scenarios] documents content adaptations that are in [I-D.ietf-opes-scenarios] documents content adaptations that are in
scope of the OPES framework (XXX provide a quote). These adaptations scope of the OPES framework. Scenarios include adaptations of
do not include URI resolution (XXX check). In some environments, it requests and responses. These adaptations do not include URI
is technically possible to adapt URIs (and other kinds of identifiers resolution adaptations. In some environments, it is technically
or addresses) using documented OPES mechanisms. possible to adapt URIs (and other kinds of identifiers or addresses)
using documented OPES mechanisms. The OPES framework cannot
effectively prohibit any specific adaptations.
8. Consideration (4.2) Reference validity 8. Consideration (4.2) 'Reference validity'
"All proposed services must define their impact on inter- and "All proposed services must define their impact on inter- and
intra-document reference validity."[RFC3238] intra-document reference validity."[RFC3238]
OPES working group does not propose adaptation services. However, The OPES framework does not propose adaptation services. However,
OPES tracing requirements include identification of OPES OPES tracing requirements include identification of OPES
intermediaries and services (for details, see "Notification" intermediaries and services (for details, see "Notification"
consideration sections in this document). It is required that consideration sections in this document). It is required that
provided identification can be used to locate information about the provided identification can be used to locate information about the
OPES intermediaries, including the description of impact on reference OPES intermediaries, including the description of impact on reference
validity (XXX quote tracing draft) [I-D.ietf-opes-end-comm]. validity [I-D.ietf-opes-end-comm] (XXX: check tracing draft for this
requirement).
9. Consideration (4.3) Addressing extensions 9. Consideration (4.3) 'Addressing extensions'
"Any services that cannot be achieved while respecting the above two "Any services that cannot be achieved while respecting the above two
considerations may be reviewed as potential requirements for Internet considerations may be reviewed as potential requirements for Internet
application addressing architecture extensions, but must not be application addressing architecture extensions, but must not be
undertaken as ad hoc fixes."[RFC3238] undertaken as ad hoc fixes."[RFC3238]
OPES framework does not contain ad hoc fixes. This and other OPES OPES framework does not contain ad hoc fixes. This document in
documents should be sufficient to inform service creators of IAB combination with and other OPES documents should be sufficient to
considerations. If a service does URI resolution or silently affects inform service creators of IAB considerations. If a service does URI
document reference validity, the authors are requested to review resolution or silently affects document reference validity, the
service impact on Internet application addressing architecture and authors are requested to review service impact on Internet
work within IETF on potential extension requirements. Such actions application addressing architecture and work within IETF on potential
would be outside of the current OPES framework. extension requirements. Such actions would be outside of the current
OPES framework.
10. Consideration (5.1) Privacy 10. Consideration (5.1) 'Privacy'
"The overall OPES framework must provide for mechanisms for end users "The overall OPES framework must provide for mechanisms for end users
to determine the privacy policies of OPES intermediaries."[RFC3238] to determine the privacy policies of OPES intermediaries."[RFC3238]
OPES tracing mechanisms allow end users to identify OPES OPES tracing mechanisms allow end users to identify OPES
intermediaries (for details, see "Notification" consideration intermediaries (for details, see "Notification" consideration
sections in this document). It is required that provided sections in this document). It is required that provided
identification can be used to locate information about the OPES identification can be used to locate information about the OPES
intermediaries, including their privacy policies. intermediaries, including their privacy policies.
The terms "privacy" and "privacy policy" are not defined in this The term "privacy policy" is not defined in this context (by IAB or
context (by IAB or OPES working group). OPES tracing mechanisms allow OPES working group). OPES tracing mechanisms allow end users and
end users and content providers to identify OPES intermediaries. It content providers to identify an OPES system and/or intermediaries.
is believed that once an intermediary is identified, it would be It is believed that once an OPES system is identified, it would be
possible to locate relevant information about that intermediary, possible to locate relevant information about that system, including
including information relevant to requesters perception of privacy information relevant to requesters perception of privacy policy or
policy or reference validity. (XXX: should we move this paragraph reference validity.
into a separate section and expand it? one the other hand, it is
probably the job of the architecture draft to define these things so
that we can refer to them from here.)
11. Security Considerations 11. Consideration 'Encryption'
XXX. "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."[RFC3238]
12. Compliance The above quoted requirement was not explicitly listed as on of the
IAB considerations, but still needs to be addressed. The context of
the quote implies that the phrase "end-to-end encryption" refers to
encryption along all links of the end-to-end path, with the OPES
intermediaries as encrypting/decrypting participants or hops (e.g.,
encryption between the provider and the OPES intermediaries, and
between the OPES intermediaries and the client).
Since OPES processors are regular hops on the application protocol
path, OPES architecture allows for such encryption, provided the
application protocol being adapted supports it. Hop-by-hop encryption
would do little good for the overall application message path
protection if callout services have to receive unencrypted content.
To allow for complete link encryption coverage, OPES callout protocol
(OCP) supports encryption of OCP connections between an OPES
processor and a callout server via optional (negotiated) transport
encryption mechanisms [I-D.ietf-opes-ocp-core].
For example, TLS encryption [RFC2817] can be used among HTTP hops
(some of which could be OPES processors) and between each OPES
processor and a callout server.
12. Security Considerations
This document does not define any mechanisms that may be subject to
security considerations. Security considerations for OPES mechanisms
are discussed in corresponding OPES framework documents.
13. Compliance
This document may be perceived as a proof of OPES compliance with IAB This document may be perceived as a proof of OPES compliance with IAB
implied recommendations. However, this document does not introduce implied recommendations. However, this document does not introduce
any compliance subjects. Compliance of OPES implementations is any compliance subjects. Compliance of OPES implementations is
defined in other OPES documents discussed above. defined in other OPES documents discussed above.
13. To-do Appendix A. Change Log
security section: Does this document have any original security Internal WG revision control ID: $Id: iab-cons.xml,v 1.26 2003/10/27
matters worth documenting? 11:40:33 rousskov Exp $
normative IDs: To be normative, OPES Internet-Drafts must be replaced 2003/10/24
with corresponding RFCs when the latter are published.
architecture draft: Should architecture draft talk about external/ * Addressed hop-by-hop encryption concerns mentioned in the IAB
internal OPES intermediaries, OPES systems, and privacy policies? draft.
Should this document be limited to a compilation of references
from other OPES drafts, or should we introduce/discuss new
concepts here?
Appendix A. Change Log * Polished IP addressing figure.
Internal WG revision control ID: $Id: iab-cons.xml,v 1.20 2003/09/24 * Removed resolved XXXs.
05:20:21 rousskov Exp $
2003/10/01
* Polishing (Abbie Barbir).
2003/09/23 2003/09/23
* Added a reference to Optional Notification section of the * Added a reference to Optional Notification section of the
ietf-opes-end-comm draft. ietf-opes-end-comm draft.
* Fixed "Consideration (3.3) Non-blocking" section position. * Fixed "Consideration (3.3) Non-blocking" section position.
head-sid15 head-sid15
skipping to change at page 23, line 9 skipping to change at page 23, line 9
* Added Abbie Barbir as an author. * Added Abbie Barbir as an author.
head-sid7 head-sid7
* Initial revision * Initial revision
Normative References Normative References
[I-D.ietf-opes-end-comm] [I-D.ietf-opes-end-comm]
Barbir, A., "OPES processor and end points Barbir, A., "OPES processor and end points
communications", draft-ietf-opes-end-comm-02 (work in communications", draft-ietf-opes-end-comm-04 (work in
progress), September 2003. progress), October 2003.
[I-D.ietf-opes-architecture] [I-D.ietf-opes-architecture]
Barbir, A., "An Architecture for Open Pluggable Edge Barbir, A., "An Architecture for Open Pluggable Edge
Services (OPES)", draft-ietf-opes-architecture-04 (work in Services (OPES)", draft-ietf-opes-architecture-04 (work in
progress), December 2002. progress), December 2002.
[I-D.ietf-opes-scenarios] [I-D.ietf-opes-scenarios]
Barbir, A., "OPES Use Cases and Deployment Scenarios", Barbir, A., "OPES Use Cases and Deployment Scenarios",
draft-ietf-opes-scenarios-01 (work in progress), August draft-ietf-opes-scenarios-01 (work in progress), August
2002. 2002.
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC Considerations for Open Pluggable Edge Services", RFC
3238, January 2002. 3238, January 2002.
Informative References Informative References
[RFC2227] Mogul, J. and P. Leach, "Simple Hit-Metering and
Usage-Limiting for HTTP", RFC 2227, October 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/
1.1", RFC 2817, May 2000.
[I-D.ietf-opes-http]
Rousskov, A. and M. Stecher, "HTTP adaptation with OPES",
draft-ietf-opes-http-00 (work in progress), August 2003.
[I-D.ietf-opes-ocp-core]
Rousskov, A., "OPES Callout Protocol Core",
draft-ietf-opes-ocp-core-01 (work in progress), August
2003.
Authors' Addresses Authors' Addresses
Abbie Barbir Abbie Barbir
Nortel Networks Nortel Networks
3500 Carling Avenue 3500 Carling Avenue
Nepean, Ontario Nepean, Ontario
CA CA
Phone: +1 613 763 5229 Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com EMail: abbieb@nortelnetworks.com
skipping to change at page 26, line 7 skipping to change at page 26, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/