draft-ietf-opes-end-comm-03.txt   draft-ietf-opes-end-comm-04.txt 
Network Working Group A. Barbir Network Working Group A. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: April 3, 2004 October 4, 2003 Expires: March 31, 2004 Oct. 2003
OPES processor and end points communications OPES entities and end points communication
draft-ietf-opes-end-comm-03 draft-ietf-opes-end-comm-04
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 30 skipping to change at page 1, line 30
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 April 3, 2004. This Internet-Draft will expire on March 31, 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
This memo documents tracing and non-blocking requirements for Open This memo documents tracing and non-blocking requirements for Open
Pluggable Edge Services (OPES). Pluggable Edge Services (OPES).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements for OPES Tracing . . . . . . . . . . . . . . . . 5 3. Requirements for OPES Tracing . . . . . . . . . . . . . . . . 5
3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . . 5 3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . . 5
3.2 Requirements for Information Related to Traceable Entities . . 6 3.2 Requirements for OPES System . . . . . . . . . . . . . . . . . 6
3.3 Requirements for OPES processors . . . . . . . . . . . . . . . 7 3.3 Requirements for OPES processors . . . . . . . . . . . . . . . 7
3.4 Requirements for callout servers . . . . . . . . . . . . . . . 7 3.4 Requirements for callout servers . . . . . . . . . . . . . . . 7
3.5 Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 8 4. Requirements for OPES System Bypass (Non-blocking feature) . . 8
4. Non-Blocking . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 What can be bypassed in an OPES Flow? . . . . . . . . . . . . 8
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 4.2 Bypass requirements for OPES System . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4.3 Bypass requirements for OPES processors . . . . . . . . . . . 9
Normative References . . . . . . . . . . . . . . . . . . . . . 14 4.4 Bypass requirements for callout servers . . . . . . . . . . . 10
Informative References . . . . . . . . . . . . . . . . . . . . 15 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 17 7.1 Tracing security considerations . . . . . . . . . . . . . . . 13
7.2 Bypass security considerations . . . . . . . . . . . . . . . . 14
Normative References . . . . . . . . . . . . . . . . . . . . . 16
Informative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
1. Introduction 1. Introduction
The Open Pluggable Edge Services (OPES) architecture [8] enables The Open Pluggable Edge Services (OPES) architecture [7] enables
cooperative application services (OPES services) between a data cooperative application services (OPES services) between a data
provider, a data consumer, and zero or more OPES processors. The provider, a data consumer, and zero or more OPES processors. The
application services under consideration analyze and possibly application services under consideration analyze and possibly
transform application-level messages exchanged between the data transform application-level messages exchanged between the data
provider and the data consumer. provider and the data consumer.
This work specify the requirements for providing tracing This work specifies the requirements for providing tracing
functionality for the OPES architecture [8]. Tracing functionality functionality for the OPES architecture [7]. Tracing functionality
enables a data provider application to detect inappropriate actions enables a data provider or a data consumer application to detect
that are performed by OPES entities. The work also develops inappropriate actions that are performed by OPES entities. The work
requirements that can be used to fulfill IAB Notification and also develops requirements that can be used to fulfill IAB
Non-Blocking requirements [2]. Notification and Bypass (Non-Blocking) requirements [2].
The architecture document requires [8] that tracing be supported The architecture document requires [7] that tracing is supported
in-band. This design goal limits the type of application protocols in-band. This design goal limits the type of application protocols
that OPES can support. The details of what a trace record can convey that OPES can support. The details of what a trace record can convey
is also dependent on the choice of the application level protocol. are also dependent on the choice of the application level protocol.
For these reasons, this work documents requirements for application For these reasons, this work documents requirements for application
protocols that need to support OPES traces and non-blocking. However, protocols that need to support OPES traces and non-blocking
the architecture does not prevent implementers of developing mechanism. However, the architecture does not prevent implementers of
out-of-band protocols and techniques to address these limitation. developing out-of-band protocols and techniques to address these
limitation.
2. OPES System 2. OPES System
This sections provides a definition of OPES System. This is needed in This sections provides a definition of OPES System. This is needed in
order to define what is traceable in an OPES Flow. order to define what is traceable in an OPES Flow.
Definition: An OPES System is a set of all OPES entities authorized Definition: An OPES System is a set of all OPES entities [7]
by either the data provider or the data consumer application to authorized by either the data provider or the data consumer
process a given application message. application to process a given application message.
The nature of the authorization agreement determines if authority The nature of the authorization agreement determines if authority
delegation is transitive (meaning an authorized entities is delegation is transitive (meaning an authorized entity is authorized
authorized to include other entities). Transitive authority to include other entities).
delegation is common in information systems.
If specific authority agreements allow for re-delegation, an OPES If specific authority agreements allow for re-delegation, an OPES
system can be formed by induction. In this case, an OPES system system can be formed by induction. In this case, an OPES system
starts with entities directly authorized by a data provider (or a starts with entities directly authorized by a data provider (or a
data consumer) application. The OPES system then includes any OPES data consumer) application. The OPES system then includes any OPES
entity authorized by an entity that is already in the OPES system. entity authorized by an entity that is already in the OPES system.
The authority delegation is always viewed in the context of a given The authority delegation is always viewed in the context of a given
application message. application message.
An OPES System is defined on an application message basis. Having an An OPES System is defined on an application message basis. Having an
authority to process a message does not imply being involved in authority to process a message does not imply being involved in
message processing. Thus, some OPES system members may not message processing. Thus, some OPES system members may not
participate in processing of a message. Similarly, some members may participate in processing of a message. Similarly, some members may
process the same message several times. process the same message several times.
The above definition implies that there can be no more than one OPES The above definition implies that there can be no more than two OPES
system processing a single message at a given time. This is based on systems [Client-side and server-side OPES systems can process the
the assumption that there is a single data provider and a single data same message at the same time] processing the same message at a given
consumer as far as a given application message is concerned. time. This is based on the assumption that there is a single data
provider and a single data consumer as far as a given application
message is concerned.
For example, consider a Content Delivery Network (CDN) delivering an For example, consider a Content Delivery Network (CDN) delivering an
image on behalf of a busy web site. OPES processors and services that image on behalf of a busy web site. OPES processors and services that
the CDN uses to adapt and deliver the message comprise an OPES the CDN uses to adapt and deliver the message comprise an OPES
system. In a more complex example, an OPES System would contain CDN System. In a more complex example, an OPES System would contain CDN
entries as well as 3rd-party OPES entities that CDN engages to entries as well as 3rd-party OPES entities that CDN engages to
perform adaptations (e.g., to adjust image quality). perform adaptations (e.g., to adjust image quality).
3. Requirements for OPES Tracing 3. Requirements for OPES Tracing
In an OPES System tracing is defined as the inclusion of necessary In an OPES System tracing is defined as the inclusion of necessary
information within a message in an OPES Flow that identify the set of information within a message in an OPES Flow that identify the
transformations or adaptations that have been performed on it before collection of transformations or adaptations that have been performed
its delivery to an end point (for example, the data consumer on it before its delivery to an end point (for example, the data
application). An OPES trace represents a snap shot of the tracing consumer application). An OPES trace represents a snap shot of the
information that have been added to a given application message. tracing information that have been added to a given application
message. A trace represents the collections of transformations on an
application message in the order that were performed. A traceable
entity can appear multiple times in a trace (every time it acts on a
message).
In an OPES System tracing is performed on per message basis. Trace In an OPES System tracing is performed on per message basis. Trace
format is dependent on the application protocol that is being adapted format is dependent on the application protocol that is being adapted
by OPES. A Data consumer application can use OPES trace to infer the by OPES. A data consumer application can use OPES trace to infer the
actions that have been performed by the OPES system. Actions are the actions that have been performed by the OPES System. Actions are the
set of authorized OPES services that were performed by OPES entities set of OPES services that were performed by OPES entities in an OPES
in an OPES System. System.
Providing tracing information, MUST take into account the following In an OPES System, the task of providing tracing information, can
considerations: depend on many factors. Some considerations are:
o Providers may be hesitant to reveal information about their o Providers may be hesitant to reveal information about their
internal network infrastructure. internal network infrastructure.
o Within a service provider network, OPES processors may be o Within a service provider network, OPES processors may be
configured to use non-routable, private IP addresses. configured to use non-routable, private IP addresses.
o A Data consumer applications would prefer to have a single point o A data consumer applications would prefer to have a single point
of contact regarding the trace information. of contact regarding the trace information.
In an OPES System some OPES services are message-agnostic and operate
on message content or parts of a message. Such services do not
manipulate message headers. Other services can manipulate message
headers. OPES providers require some freedom in the way they deliver
tracing information to an end point.
3.1 What is traceable in an OPES Flow? 3.1 What is traceable in an OPES Flow?
This section focuses on identifying traceable entities in an OPES This section focuses on identifying traceable entities in an OPES
Flow. Flow.
Tracing information provides a data consumer application (or a data Tracing information provides a data consumer application (or a data
provider application) with useful information without tracing the provider application) with information about OPES entities that
exact OPES Processor or callout servers that adapted the data. For adapted the data. There are two distinct uses of OPES traces. First,
example, some OPES services are message-agnostic and operate on a trace enables an "end (content provider or consumer) to detect the
message content or parts of a message. Such services cannot presence of OPES processors within an OPES System. Such "end" should
manipulate message headers. Hence, a data consumer application would be able to see a trace entry, but does not need to be able to
be interested in knowing that a translation service on the message interpret it beyond identification of the OPES System.
content was performed. It does not need to know the exact entity that
has performed the service.
There are two distinct uses of OPES traces. First, a trace enables an
"end (content provider or consumer) to detect the presence of OPES
processors within an OPES System. Such "end" should be able to see a
trace entry, but does not need to be able to interpret it beyond
identification of the OPES System.
Second, the OPES System administrator is expected to be able to Second, the OPES System administrator is expected to be able to
interpret the contents of an OPES trace. The trace can be provided by interpret the contents of an OPES trace. The trace can be relayed to
an end (data consumer or provider) as an opaque string. The the administrator by an end (data consumer or provider) without
administrator can use the trace information to identify the interpretation, as opaque data (e.g., a TCP packet or an HTTP message
participating OPES processor(s). The administrator can use the trace snapshot). The administrator can use the trace information to
to identify the applied adaptation services along with other identify the participating OPES entities. The administrator can use
message-specific information. the trace to identify the applied adaptation services along with
other message-specific information.
Since the administrators of various OPES Systems can have various Since the administrators of various OPES Systems can have various
ways of looking into tracing, they MAY require the choice of freedom ways of looking into tracing, they require the choice of freedom in
in what to put in trace records and how to format them. Trace records what to put in trace records and how to format them. Trace records
should be easy to extend beyond basic OPES requirements. Trace should be easy to extend beyond basic OPES requirements. Trace
management algorithms should treat trace records as opaque data to management algorithms should treat trace records as opaque data to
the extent possible. the extent possible.
At the implementation level, for a given trace, an OPES entity At the implementation level, for a given trace, an OPES entity
involved in handling the corresponding application message is involved in handling the corresponding application message is
traceable or traced if information about it appears in that trace. traceable or traced if information about it appears in that trace.
OPES entities have different levels of traceability requirements. OPES entities have different levels of traceability requirements.
Specifically, Specifically,
o An OPES system MUST add its entry to the trace.
o An OPES processor SHOULD add its entry to the trace. o An OPES processor SHOULD add its entry to the trace.
o An OPES service May add its entry to the trace. o An OPES service May add its entry to the trace.
o An OPES entity MAY manage trace information from entities that are o An OPES entity MAY delegate addition of its trace entry to another
under its control. For example, an OPES processor may add or OPES entity. For example, an OPES System can have a dedicated OPES
remove callout service entries in order to manage the size of a processor for adding System entries; an OPES processor can use a
trace. callout service to manage all OPES trace manipulations (since such
manipulations are OPES adaptations).
From an OPES context, a good tracing approach is similar to a trouble In an OPES context, a good tracing approach is similar to a trouble
ticket ready for submission to a known address. The address is ticket ready for submission to a known address. The address is
printed on the ticket. The trace in itself is not necessarily a printed on the ticket. The trace in itself is not necessarily a
detailed description of what has happened. It is the responsibility detailed description of what has happened. It is the responsibility
of the operator to resolve the problems. of the operator to resolve the problems.
3.2 Requirements for Information Related to Traceable Entities 3.2 Requirements for OPES System
The following MUST requirements apply for information as related to The following requirements apply for information as related to an
entities that are traceable in an OPES flow: OPES System:
o Identification of the OPES System privacy policy at the time it o An OPES system MUST add its identification to the trace.
dealt with the message.
o Identification of the party responsible for setting and enforcing o An OPES System MUST include information about its privacy policy.
that policy.
o Information pointing to a technical contact. o An OPES System MUST identify the party responsible for setting and
enforcing that policy.
o Information that identifies, to the technical contact, the OPES o An OPES System MUST include information pointing to a technical
processors involved in processing the message. contact.
3.3 Requirements for OPES processors o An OPES System MUST include information that identifies, to the
technical contact, the OPES processors involved in processing the
message.
The requirements for OPES processors that are applicable to tracing In addressing the above requirements and in order to reduce the size
are: of the trace, an OPES System can provide a URL to the OPES System web
page that has links to privacy and other policies.
o Each OPES processor MUST be uniquely identified in an OPES System. 3.3 Requirements for OPES processors
Tracing requirements for OPES processors are:
o Each OPES processor MUST support tracing, policy can be used to o Each OPES processor MUST support tracing, policy can be used to
turn tracing on and to determine its granularity. turn tracing on and to determine its granularity.
o If tracing is turned on, then the OPES processor MUST add its o If tracing is turned on, OPES processor SHOULD add its unique
identification to the trace. identification to the trace. Here, uniqueness scope is the OPES
System containing the processor.
o OPES processor SHOULD be able to trace it's own invocation and o OPES processor SHOULD be able to trace it's own invocation and
service(s) execution since it understands the application service(s) execution since it understands the application
protocol. To fulfill this: protocol.
* An OPES processor MAY have a fixed configuration that enable it
to respond to tracing inquires. For example, entity X performs
service Y and so on.
* An OPES processor MAY package tracing information related to
the entities that it control based on the policy of a given
OPES System. For example, the trace may state that service W
was performed. The OPES processor knows that service W is
composed of services X, Y and Z in a given order
o An OPES processor SHOULD add to the trace identification of every
callout service that processed the application message.
o An OPES processor MAY delegate trace management to a callout
service within the same OPES System.
3.4 Requirements for callout servers 3.4 Requirements for callout servers
In an OPES system, it is the task of an OPES processor to add trace In an OPES system, it is the task of an OPES processor to add trace
records to application messages. However, in some cases, callout records to application messages. However, in some cases, callout
servers May add trace information to application messages. This servers May add trace information to application messages. This
should be done under the control of the OPES System provider. should be done under the control of the OPES System provider.
3.5 Protocol Binding 4. Requirements for OPES System Bypass (Non-blocking feature)
The task of adding tracing information is application protocol IAB recommendation (3.3) [2] requires that the OPES architecture does
specific. Separate documents will address HTTP and other protocols. not prevent a data consumer application from retrieving non-OPES
This work documents what tracing information is required and some version of content from a data provider application, provided that
common tracing elements. the non-OPES content exists. IAB recommendation (3.3) suggests that
the Non-blocking feature (Bypass) be used to bypass faulty OPES
intermediaries (once they have been identified, by some method).
4. Non-Blocking In addressing IAB consideration (3.3), one need to specify what
constitute non-OPES content. In some cases, the definition of
"non-OPES" content is provider-dependent and may include content
adapted by OPES. Examples include content that is adapted for Black
and White hand held devices or logging services. In other cases, the
availability of certain content can be a function of the internal
policy of a given organization that has contracted the services of an
OPES provider. For example, Company A has as contract with an OPES
provider to perform virus checking on all e-mail attachments. An
employee X of Company A can issue a non-blocking request for the
virus scanning service. However, the request could be ignored by the
OPES provider since it contradicts its agreement with Company A.
In [9] recommendation addresses the issue of non-blocking in an OPES The above examples illustrates that the availability of non-OPES
System. The recommendation is restated below for ease of reference. content can be a function of content providers (or consumers or both)
policy and deployment scenarios [1]. For this reason, this work does
not attempt to define what is an OPES content as opposed to non-OPES
content. The meaning of OPES versus non-OPES content is assumed to be
determined through various agreements between the OPES provider, data
provider and data consumer application. The agreement will also
determine what OPES services can be bypassed and in what order (if
applicable).
(3.3) Non-blocking: If there exists a non-OPES version of content In an OPES System a Bypass request is defined as the act of avoiding
available from the content provider, the OPES architecture must the invocation of a service(s) that is identified by a URI within a
not prevent users from retrieving this non-OPES version from the message in an OPES Flow before its delivery to an end point (for
content provider. example, the data consumer application).
The IAB recommendation implies that it is up to the content provider 4.1 What can be bypassed in an OPES Flow?
to make non-OPES versions of a given content available. The actual
meaning of non-OPES version of the content depended on the agreement
between the OPES provider and the content provider. The agreement can
allow OPES to perform some services (such as logging services) and
prevent it from performing other services (such as data to audio
transformation).
Whether an OPES System honor a non-blocking request from a data In this work, the focus is on developing a bypass feature that allow
consumer application (user) can also be a function of deployment. a user to instruct the OPES System to bypass some or all of its
Consider the case where Company A has as contract with an OPES services. The collection of OPES services that can be bypassed is a
provider to perform virus checking on all e-mail attachments. An function of the agreement of the OPES provider with either (or both)
employee X of Company A can issue a non-blocking request for the the content provider or the content consumer applications. In the
virus scanning service. However, the request could be ignored by the general case, a Bypass request is viewed as a bypass instruction that
OPES provider since it contradicts its agreement with Company A. As contains a URI that identifies an OPES entity or a group of OPES
a second example, a user may issue a non-blocking request for adult entities that perform a service (or services) to be bypassed. An
content, this request may be declined by the OPES provider simply instruction may contain more than one such URI. A special wildcard
because it contradicts its internal policy or its agreement with the identifier can be used to represent all possible URIs (i.e., all
end subscriber. possible OPES services).
In some cases, a data consumer application will issue a non-blocking 4.2 Bypass requirements for OPES System
request since it suspects that the OPES System is corrupting the
data. For example, an OPES entity has determined that a Virus is In an OPES System the Bypass feature is an end-to-end operation as
present in an attachment, while the user is aware that some versions opposed to a hop-by-hop operation. Bypass requests are generally
of virus scanners will make that mistake. In this case, the user can client centric and go in the opposite direction of tracing requests.
use the non-blocking technique (can be used in combination with the Bypass can be performed out of band or in-band. This work requires
tracing facility) to solve the problem. However, whether the OPES that the Bypass feature be performed in-band as an extension to an
System will honor the non-blocking request or not is still a function application specific protocol. Non-OPES entities should be able to
of the deployment scenario, content availability and related safely ignore these extensions. The work does not prevent OPES
Systems from developing their own out of band protocols.
The following requirements apply for Bypass feature as related to an
OPES System:
o An OPES system MUST support a Bypass feature. This means that the
OPES System bypasses an entity whose URI is identified by an OPES
end (usually data consumer application).
o An OPES System MUST treat a Bypass request as an end-to-end
operation. This applies to the whole system.
o An OPES System MUST include information about its bypass policy.
o An OPES System MUST identify the party responsible for setting and
enforcing the bypass policy.
o An OPES System MUST include information that identifies, to a
technical contact, the OPES processors involved in processing the
bypass request.
In addressing the above requirements an OPES System can provide a URL
to the OPES System web page that has links to Bypass and other
policies. policies.
Like tracing, Non-blocking operates on per application message bases. In order to facilitate the debugging (or data consumer user
Non-Blocking is an end-end operation as opposed to a hop-by-hop experience) of the bypass feature in an OPES System, it would be
operation. Non-blocking requests are generally client centric and go beneficial if non-bypassed entities include information related to
in the opposite direction of tracing requests. Non-blocking can be why they ignored the bypass instruction. It is important to note that
performed out of band or in-band. This work requires non-blocking to in some cases the tracing facility itself may be broken and the whole
be performed in-band as an extension to an application specific OPES System (or part) may need to be bypassed through the issue of a
protocol. Non-OPES entities should be able to safely ignore the bypass instruction.
extensions. The work does not prevent OPES Systems from developing
their own out of band protocols.
Non-blocking format is dependent on the application protocol that is 4.3 Bypass requirements for OPES processors
being adapted by OPES. For a given application protocol, in an OPES
System there can be services that operate on application message
headers and those that just operate on content. This mix of service
requires that an OPES processor that is calling the service(s) to
handle the non-blocking request. In some cases, the first OPES
processor that will get the non-blocking request may not be the first
OPES processor that will know whether a non-OPES version of the
content is available or not.
In an OPES System, the OPES provider is expected to configure at For a given application protocol, in an OPES System there can be
least one OPES processor to process a non-blocking header based on services that operate on application message headers and those that
content availability and related policies. In this case the OPES just operate on content. This mix of service requires that an OPES
processor is expected to determine the set of services that will be processor that is calling the service(s) to handle the bypass
bypassed (or those services that will be performed) or whether the request. In some cases, the first OPES processor that will get the
request should be forwarded directly to the data provider application bypass request may not be the first OPES processor that will know
(origin content provider). whether a non-OPES version of the content is available or not.
Although, IAB recommendation (3.3) has intended for non-blocking Bypass requirements for OPES processors are:
approach to be used as a vehicle to bypass faulty OPES
intermediaries. However, this work recognizes that the same technique
can be used to enable a data consumer application to select the set
of services that it would like to be bypassed for a given application
message. For this reason, a non-blocking request is viewed as a
bypass instruction that contains a URI that identifies an OPES entity
or a group of OPES entities that perform a service (or services) to
be bypassed. An instruction may contain more than one such URI. A
special wildcard identifier can be used to represent all possible
URIs (i.e., all possible OPES services). This version of the work
requires that all non-blocking instructions to use the wildcard
approach.
For example, an application level protocol (such as HTTP) can be o There MUST be at least one OPES processor in an OPES System that
extended to include the following OPES non-blocking related header: knows how to interpret and process a bypass request. This
requirement applies to all bypass instructions, including those
that identify known-to-recipient entities.
OPES-Bypass: * o OPES processors that do not know how to process a bypass request
MUST forward the request to the next application hop provided that
the next hop speaks application protocol with OPES bypass support.
The following requirements apply for non-blocking feature: o The recipient of a bypass instruction with a URI that does not
identify any known-to-recipient OPES entity MUST treat that URI as
a wildcard identifier (meaning bypass all applicable services).
o An OPES System MUST support the non-blocking feature for requests o OPES processor SHOULD be able to bypass it's own invocation and
of non-OPES content for a given application message. service(s) execution since it understands the application
protocol.
o An OPES System MUST treat the non-blocking feature as an 4.4 Bypass requirements for callout servers
end-to-end operation.
* This means that there MUST be at least one OPES processor in an In an OPES system, it is the task of an OPES processor to process
OPES System that knows how to interpret and process the bypass requests. However, in some cases, callout servers May be
non-blocking feature. involved in processing Bypass requests. This should be done under the
control of the OPES System provider.
* The recipient MUST forward the bypass instructions to the next 5. Protocol Binding
application hop provided that the next hop speaks application
protocol with OPES bypass support.
* This requirement applies to all bypass instructions, including The task of encoding tracing and bypass features is application
those that identify known-to-recipient entities. protocol specific. Separate documents will address HTTP and other
protocols.
o Application-specific bindings MUST map the above non-blocking 6. IANA considerations
mechanism to their application protocol.
End users may not be able to know if their non-blocking request was This specification contains no IANA considerations. Application
honored or not by the OPES System. In this case, it would be bindings MAY contain application-specific IANA considerations.
beneficial if tracing can provide additional information regarding
whether a non-blocking request was honored or not. For this reason,
the following requirement also apply to the tracing facility:
o An OPES System SHOULD assist the data consumer application in 7. Security Considerations
determining if a non-blocking request was performed by the system.
Assistance is viewed as the addition of information about services The security considerations for OPES are documented in [6]. This
that were skipped and those that could not be bypassed. document is a requirement document for tracing and Bypass feature.
The requirements that are stated in this document can be used to
extend an application level protocol to support these features. As
such, the work has security precautions.
5. IANA considerations 7.1 Tracing security considerations
This work does not require any IANA consideration since any actions The tracing facility for OPES architecture is implemented as a
will be addressed in [6]. protocol extension. Inadequate implementations of the tracing
facility may defeat safeguards built into the OPES architecture. The
tracing facility by itself can become a target of malicious attacks
or used to lunch attacks on an OPES System.
6. Security Considerations Threats caused by or against the tracing facility can be viewed as
threats at the application level in an OPES Flow. In this case, the
threats can affect the data consumer and the data provider
application.
The security considerations for OPES are documented in [7]. This Since tracing information is a protocol extension, these traces can
document is a requirement document for tracing and non-blocking and be injected in the data flow by non-OPES entities. In this case,
as such does not develop any new protocols that require security there are risks that non-OPES entities can be compromised in a
considerations. fashion that threat the overall integrity and effectiveness of an
OPES System. For example, a non-OPES proxy can add fake tracing
information into a trace. This can be done in the form of wrong, or
unwanted, or non existent services. A non-OPES entity can inject
large size traces that may cause buffer overflow in a data consumer
application. The same threats can arise from compromised OPES
entities. An attacker can control an OPES entity and inject wrong, or
very large trace information that can overwhelm an end or the next
OPES entity in an OPES flow. Similar threats can result from bad
implementations of the tracing facility in trusted OPES entities.
Compromised tracing information can be used to launch attacks on an
OPES System that give the impression that unwanted content
transformation was performed on the data. This can be achieved by
inserting wrong entity (such OPES processor) identifiers. A
compromised trace can affect the overall message integrity structure.
This can affect entities that use message header information to
perform services such as accounting, load balancing, or
reference-based services.
Compromised trace information can be used to launch DoS attacks that
can overwhelm a data consumer application or an OPES entity in an
OPES Flow. Inserting wrong tracing information can complicates the
debugging tasks performed by system administrator during trouble
shooting of OPES System behavior.
Specific protocol binding documents ought to take these security
threats into consideration. It is recommended that protocol bindings
provide safe features into their specifications. Such features may
include a place holder in the message header that indicates the size
of the trace. Other holders can include the option of signing the
trace information as a proof of authenticity.
As a precaution, OPES entities ought to be capable of verifying that
the inserted traces are performed by legal OPES entities. This can be
done as part of the authorization and authentication face. Policy can
be used to indicate what trace information can be expected from a
peer entity. Other application level related security concerns can be
found in [6].
7.2 Bypass security considerations
The bypass facility for OPES architecture is implemented as a
protocol extension. Inadequate implementations of the bypass facility
may defeat safeguards built into the OPES architecture. The bypass
facility by itself can become a target of malicious attacks or used
to lunch attacks on an OPES System.
Threats caused by or against the bypass facility can be viewed as
threats at the application level in an OPES Flow. In this case, the
threats can affect the data consumer and the data provider
application.
There are risks for the OPES System by non-OPES entities, whereby,
these entities can insert bypass instructions into the OPES Flow. The
threat can come from compromised non-OPES entities. The threat might
affect the overall integrity and effectiveness of an OPES System. For
example, a non-OPES proxy can add bypass instruction to bypass
legitimate OPES entities. The attack might result in overwhelming the
original content provider servers, since the attack essentially
bypass any load balancing techniques. In addition, such an attack is
also equivalent to a DoS attack, whereby, a legitimate data consumer
application may not be able to access some content from a content
provider or its OPES version.
Since an OPES Flow may include non-OPES entities, it is susceptible
to man-in-the-middle attacks, whereby an intruder may inject bypass
instructions into the data path. These attacks may affect content
availability or disturb load balancing techniques in the network.
The above threats can also arise by compromised OPES entities. An
intruder can compromise an OPES entities and then use
man-in-the-middle techniques to disturb content availability to a
data consumer application or overload a content provider server
(essentially, some form of a DoS attack).
Attackers can use the bypass instruction to affect the overall
integrity of the OPES System. The ability to illegally introduce
bypass instructions into a data flow may effect the accounting of the
OPES System. It may also affect the quality of content that is
delivered to the data consumer applications. Similar threats can
arise from bad implementations of the bypass facility.
Specific protocol binding documents ought to take these security
threats into consideration. It is recommended that protocol bindings
provide safe features into their specifications. Such features may
include a place holder in the message header that indicates who
originated the bypass request. Other holders can include the option
of signing the bypass request as a proof of identity. Other
application level related security concerns can be found in [6].
Normative References Normative References
[1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", [1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios",
Internet-Draft http://www.ietf.org/internet-drafts/ Internet-Draft http://www.ietf.org/internet-drafts/
draft-ietf-opes-scenarios-01.txt, August 2002. draft-ietf-opes-scenarios-01.txt, August 2002.
Informative References
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238, Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002. January 2002.
[3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[4] A. Barbir et al., "Policy, Authorization and Enforcement [4] A. Barbir et al., "Policy, Authorization and Enforcement
Requirements of OPES", Internet-Draft http://www.ietf.org/ Requirements of OPES", Internet-Draft http://www.ietf.org/
internet-drafts/draft-ietf-opes-authorization-02.txt, February internet-drafts/draft-ietf-opes-authorization-02.txt, February
2003. 2003.
[5] Rousskov, A., "OPES Callout Protocol Core", Internet-Draft [5] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD,
http://www.ietf.org/internet-drafts/
draft-ietf-opes-ocp-core-01.txt, August 2003.
[6] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD,
September 2003. September 2003.
[7] A. Barbir et al., "Security Threats and Risks for Open Pluggable [6] A. Barbir et al., "Security Threats and Risks for Open Pluggable
Edge Services", Internet-Draft http://www.ietf.org/ Edge Services", Internet-Draft http://www.ietf.org/
internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. internet-drafts/draft-ietf-opes-threats-02.txt, February 2003.
[8] A. Barbir et al., "An Architecture for Open Pluggable Edge [7] A. Barbir et al., "An Architecture for Open Pluggable Edge
Services (OPES)", Internet-Draft http://www.ietf.org/ Services (OPES)", Internet-Draft http://www.ietf.org/
internet-drafts/draft-ietf-opes-architecture-04, December 2002. internet-drafts/draft-ietf-opes-architecture-04, December 2002.
[9] A. Barbir et al., "OPES Treatment of IAB Considerations", [8] A. Barbir et al., "OPES Treatment of IAB Considerations",
Internet-Draft http://www.ietf.org/internet-drafts/ Internet-Draft http://www.ietf.org/internet-drafts/
draft-ietf-opes-iab-01.txt, February 2004. draft-ietf-opes-iab-02.txt, February 2004.
Informative References
[10] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
Waldbusser, "Terminology for Policy-Based Management", RFC
3198, November 2001.
[11] L. Cranor, et. al, "The Platform for Privacy Preferences 1.0
(P3P1.0) Specification", W3C Recommendation 16 http://
www.w3.org/TR/2002/REC-P3P-20020416/ , April 2002.
Author's Address Author's Address
Abbie Barbir Abbie Barbir
Nortel Networks Nortel Networks
3500 Carling Avenue 3500 Carling Avenue
Nepean, Ontario K2H 8E9 Nepean, Ontario K2H 8E9
Canada Canada
Phone: +1 613 763 5229 Phone: +1 613 763 5229
 End of changes. 

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