draft-ietf-opes-end-comm-05.txt   draft-ietf-opes-end-comm-06.txt 
Network Working Group A. Barbir Open Pluggable Edge Services A. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: March 31, 2004 Oct. 2003 Expires: May 31, 2004 Dec. 2003
OPES entities and end points communication OPES entities and end points communication
draft-ietf-opes-end-comm-05 draft-ietf-opes-end-comm-06
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 March 31, 2004. This Internet-Draft will expire on May 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 (bypass) requirements This memo documents tracing and non-blocking (bypass) requirements
for Open Pluggable Edge Services (OPES). for Open Pluggable Edge Services (OPES).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements for OPES Tracing . . . . . . . . . . . . . . . . 5 3. Tracing Requirements . . . . . . . . . . . . . . . . . . . . . 5
3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . . 5 3.1 Traceable entities . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Requirements for OPES System . . . . . . . . . . . . . . . . . 6 3.2 System requirements . . . . . . . . . . . . . . . . . . . . . 6
3.3 Requirements for OPES processors . . . . . . . . . . . . . . . 7 3.3 Processor requirements . . . . . . . . . . . . . . . . . . . . 7
3.4 Requirements for callout servers . . . . . . . . . . . . . . . 7 3.4 Callout server requirements . . . . . . . . . . . . . . . . . 7
4. Requirements for OPES System Bypass (Non-blocking feature) . . 8 4. Bypass (Non-blocking feature) Requirements . . . . . . . . . . 8
4.1 What can be bypassed in an OPES Flow? . . . . . . . . . . . . 8 4.1 Bypassable entities . . . . . . . . . . . . . . . . . . . . . 9
4.2 Bypass requirements for OPES System . . . . . . . . . . . . . 9 4.2 System requirements . . . . . . . . . . . . . . . . . . . . . 9
4.3 Bypass requirements for OPES processors . . . . . . . . . . . 10 4.3 Processor requirements . . . . . . . . . . . . . . . . . . . . 10
4.4 Bypass requirements for callout servers . . . . . . . . . . . 10 4.4 Callout server requirements . . . . . . . . . . . . . . . . . 10
5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 11
6. Compliance Considerations . . . . . . . . . . . . . . . . . . 12 6. Compliance Considerations . . . . . . . . . . . . . . . . . . 12
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1 Tracing security considerations . . . . . . . . . . . . . . . 14 8.1 Tracing security considerations . . . . . . . . . . . . . . . 14
8.2 Bypass security considerations . . . . . . . . . . . . . . . . 15 8.2 Bypass security considerations . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . . 17 Normative References . . . . . . . . . . . . . . . . . . . . . 17
Informative References . . . . . . . . . . . . . . . . . . . . 18 Informative References . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 20
1. Introduction 1. Introduction
The Open Pluggable Edge Services (OPES) architecture [8] enables The Open Pluggable Edge Services (OPES) architecture [1] 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 specifies the requirements for providing tracing This work specifies OPES tracing and bypass functionality. The
functionality for the OPES architecture [8]. Tracing functionality architecture document [1] requires that tracing is supported in-band.
enables a data provider or a data consumer application to detect This design goal limits the type of application protocols that OPES
inappropriate actions that are performed by OPES entities. The work can support. The details of what a trace record can convey are also
also develops requirements that can be used to fulfill IAB dependent on the choice of the application level protocol. For these
Notification and Bypass (Non-Blocking) requirements [2]. reasons, this work only documents requirements for OPES entities that
are needed to support traces and bypass functionality. The task of
encoding tracing and bypass features is application protocol
specific. Separate documents will address HTTP and other protocols.
The architecture document requires [8] that tracing is supported The architecture does not prevent implementers from developing
in-band. This design goal limits the type of application protocols out-of-band protocols and techniques to address tracing and bypass.
that OPES can support. The details of what a trace record can convey Such protocols are out of scope of the current work.
are also dependent on the choice of the application level protocol.
For these reasons, this work documents requirements for application 1.1 Terminology
protocols that need to support OPES traces and non-blocking
mechanism. The architecture does not prevent implementers of The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
developing out-of-band protocols and techniques to address these "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
limitation. In this document the key words that are used to signify document are to be interpreted as described in RFC 2119 [2]. When
requirements are based on RFC 2119 [3]. used with the normative meanings, these keywords will be all
uppercase. Occurrences of these words in lowercase comprise normal
prose usage, with no normative implications.
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 (or bypassable) in an OPES Flow.
Definition: An OPES System is a set of all OPES entities [8] Definition: An OPES System is a set of all OPES entities authorized
authorized by either the data provider or the data consumer by either the data provider or the data consumer application to
application to process a given application message. 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 entity is authorized delegation is transitive (meaning an authorized entity is authorized
to include other entities). to include other entities).
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.
skipping to change at page 4, line 41 skipping to change at page 4, line 41
The above definition implies that there can be no more than two OPES The above definition implies that there can be no more than two OPES
systems [Client-side and server-side OPES systems can process the systems [Client-side and server-side OPES systems can process the
same message at the same time] processing the same message at a given same message at the same time] processing the same message at a given
time. This is based on the assumption that there is a single data 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 provider and a single data consumer as far as a given application
message is concerned. 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 image comprise an OPES System.
System. In a more complex example, an OPES System would contain CDN In a more complex example, an OPES System would contain third party
entries as well as 3rd-party OPES entities that CDN engages to OPES entities that the CDN engages to perform adaptations (e.g., to
perform adaptations (e.g., to adjust image quality). adjust image quality).
3. Requirements for OPES Tracing
In an OPES System tracing is defined as the inclusion of necessary
information within a message in an OPES Flow that identify the
collection of transformations or adaptations that have been performed
on it before its delivery to an end point (for example, the data
consumer application). An OPES trace represents a snap shot of the
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
format is dependent on the application protocol that is being adapted
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
set of OPES services that were performed by OPES entities in an OPES
System.
In an OPES System, the task of providing tracing information, can 3. Tracing Requirements
depend on many factors. Some considerations are:
o Providers may be hesitant to reveal information about their The definition of OPES trace and tracing are given next.
internal network infrastructure.
o Within a service provider network, OPES processors may be OPES trace: application message information about OPES entities
configured to use non-routable, private IP addresses. that adapted the message.
o A data consumer applications would prefer to have a single point OPES tracing: the process of creating, manipulating, or
of contact regarding the trace information. interpreting an OPES trace.
In an OPES System some OPES services are message-agnostic and operate Note that the above trace definition assumes in-band tracing. This
on message content or parts of a message. Such services do not dependency can be removed if desired. Tracing is performed on per
manipulate message headers. Other services can manipulate message message basis. Trace format is dependent on the application protocol
headers. OPES providers require some freedom in the way they deliver that is being adapted. A traceable entity can appear multiple times
tracing information to an end point. in a trace (for example, every time it acts on a message).
3.1 What is traceable in an OPES Flow? 3.1 Traceable entities
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 an "end" with information about OPES
provider application) with information about OPES entities that entities that adapted the data. There are two distinct uses of OPES
adapted the data. There are two distinct uses of OPES traces. First, traces. First, a trace enables an "end" to detect the presence of
a trace enables an "end (content provider or consumer) to detect the OPES System. Such "end" should be able to see a trace entry, but does
presence of OPES processors within an OPES System. Such "end" should not need to be able to interpret it beyond identification of the OPES
be able to see a trace entry, but does not need to be able to System and location of certain required OPES-related disclosures (see
interpret it beyond identification of the OPES System. Section 3.2).
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 relayed to interpret the contents of an OPES trace. The trace can be relayed to
the administrator by an end (data consumer or provider) without the administrator by an "end" without interpretation, as opaque data
interpretation, as opaque data (e.g., a TCP packet or an HTTP message (e.g., a TCP packet or an HTTP message snapshot). The administrator
snapshot). The administrator can use the trace information to can use the trace information to identify the participating OPES
identify the participating OPES entities. The administrator can use entities. The administrator can use the trace to identify the applied
the trace to identify the applied adaptation services along with adaptation services along with other message-specific information.
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 require the choice of freedom in ways of looking into tracing, they require the freedom in what to put
what to put in trace records and how to format them. Trace records in trace records and how to format them.
should be easy to extend beyond basic OPES requirements. Trace
management algorithms should treat trace records as opaque data to
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.
This work does not specify any order to that information. The order
of information in a trace can be OPES System specific or can be
defined by application bindings documents.
OPES entities have different levels of traceability requirements. OPES entities have different levels of traceability requirements.
Specifically, Specifically,
o An OPES processor MUST add its entry to the trace. 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 service MAY add its entry to the trace. o An OPES service MAY add its entry to the trace.
o An OPES entity MAY delegate addition of its trace entry to another o An OPES entity MAY delegate addition of its trace entry to another
OPES entity. For example, an OPES System can have a dedicated OPES OPES entity. For example, an OPES System can have a dedicated OPES
processor for adding System entries; an OPES processor can use a processor for adding System entries; an OPES processor can use a
callout service to manage all OPES trace manipulations (since such callout service to manage all OPES trace manipulations (since such
manipulations are OPES adaptations). manipulations are OPES adaptations).
In 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 decode trace details and to resolve the problems.
3.2 Requirements for OPES System
The following requirements apply for information as related to an 3.2 System requirements
OPES System:
o An OPES System MUST trace itself. The following requirements document actions when forming an OPES
System trace entry:
o An OPES System MUST include information about its privacy policy. o OPES system MUST include its unique identification in its trace
entry. Here, uniqueness scope is all OPES Systems that may adapt
the message being traced.
o An OPES System MUST identify the party responsible for setting and o An OPES System MUST define its impact on inter- and intra-document
enforcing that policy. reference validity.
o An OPES System MUST include information pointing to a technical o An OPES System MUST include information about its privacy policy,
contact. including identity of the party responsible for setting and
enforcing the policy.
o An OPES System MUST include information that identifies, to the o An OPES System SHOULD include information that identifies, to the
technical contact, the OPES processors involved in processing the technical contact, the OPES processors involved in processing the
message. message.
o When providing required information, an OPES System MAY use a o When providing required information, an OPES System MAY use a
single URI to identify a resource containing several required single URI to identify a resource containing several required
items. For example, an OPES System can point to a single web page items. For example, an OPES System can point to a single web page
with a reference to System privacy policy and technical contact with a reference to System privacy policy and technical contact
information. information.
This specification does not define the meaning of the terms privacy This specification does not define the meaning of the terms privacy
policy, policy enforcement, or technical contact and contains no policy, policy enforcement, or reference validity or technical
requirements regarding encoding, language, format, or any other contact and contains no requirements regarding encoding, language,
aspects of that information. Furthermore, an example of System format, or any other aspects of that information. For example, a URI
identification would be something like http://www.examplecompany.com/ used for an OPES System trace entry may look like "http://
opes/?client=example.com. www.examplecompany.com/opes/?client=example.com" where the identified
web page is dynamically generated and contains the all OPES System
information required above.
3.3 Requirements for OPES processors 3.3 Processor requirements
Tracing requirements for OPES processors are: The following requirements document actions when forming an OPES
System trace entry:
o OPES processor MUST add its unique identification to the trace. o OPES processor SHOULD add its unique identification to the trace.
Here, uniqueness scope is the OPES System containing the Here, uniqueness scope is the OPES System containing the
processor. processor.
o OPES processor MUST be able to trace it's own invocation and 3.4 Callout server requirements
service(s) execution.
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. The OPES System administrator
servers may add trace information to application messages. This decides if and under what conditions callout servers may add trace
should be done under the control of the OPES System provider. information to application messages.
4. Requirements for OPES System Bypass (Non-blocking feature) 4. Bypass (Non-blocking feature) Requirements
IAB recommendation (3.3) [2] requires that the OPES architecture does IAB recommendation (3.3) [4] requires that the OPES architecture does
not prevent a data consumer application from retrieving non-OPES not prevent a data consumer application from retrieving non-OPES
version of content from a data provider application, provided that version of content from a data provider application, provided that
the non-OPES content exists. IAB recommendation (3.3) suggests that the non-OPES content exists. IAB recommendation (3.3) suggests that
the Non-blocking feature (Bypass) be used to bypass faulty OPES the Non-blocking feature (bypass) be used to bypass faulty OPES
intermediaries (once they have been identified, by some method). intermediaries (once they have been identified, by some method).
In addressing IAB consideration (3.3), one need to specify what In addressing IAB consideration (3.3), one need to specify what
constitute non-OPES content. In this work the definition of constitutes non-OPES content. In this work the definition of
"non-OPES" content is provider dependent. However, in some cases, the "non-OPES" content is provider dependent. In some cases, the
availability of "non-OPES" content can also be a function of the availability of "non-OPES" content can be a function of the internal
internal policy of a given organization that has contracted the policy of a given organization that has contracted the services of an
services of an OPES provider. For example, Company A has as contract OPES provider. For example, Company A has as contract with an OPES
with an OPES provider to perform virus checking on all e-mail provider to perform virus checking on all e-mail attachments. An
attachments. An employee X of Company A can issue a non-blocking employee X of Company A can issue a non-blocking request for the
request for the virus scanning service. However, the request could be virus scanning service. The request could be ignored by the OPES
ignored by the OPES provider since it contradicts its agreement with provider since it contradicts its agreement with Company A.
Company A.
The above examples illustrates that the availability of non-OPES The availability of non-OPES content can be a function of content
content can be a function of content providers (or consumers or both) providers (or consumers or both) policy and deployment scenarios [3].
policy and deployment scenarios [1]. For this reason, this work does For this reason, this work does not attempt to define what is an OPES
not attempt to define what is an OPES content as opposed to non-OPES content as opposed to non-OPES content. The meaning of OPES versus
content. The meaning of OPES versus non-OPES content is assumed to be non-OPES content is assumed to be determined through various
determined through various agreements between the OPES provider, data agreements between the OPES provider, data provider and/or data
provider and data consumer application. The agreement will also consumer. The agreement determines what OPES services can be bypassed
determine what OPES services can be bypassed and in what order (if and in what order (if applicable).
applicable).
In an OPES System a bypass request is defined as the act of avoiding This specification documents bypassing of an OPES service or a group
the invocation of a service(s) that is identified by a URI within a of services identified by a URI. In this context, to "bypass the
message in an OPES Flow before its delivery to an end point (for service" for a given application message in an OPES Flow means to
example, the data consumer application). The availability of non-OPES "not invoke the service" for that application message. A bypass URI
content is a precondition to whether a bypass instruction is honored that identifies an OPES system (processor) matches all services
or not in an OPES System. attached to that OPES system (processor). However, bypassing of OPES
processors and OPES Systems themselves requires non-OPES mechanisms
and is out of this specification scope. A bypass request an
instruction to bypass, usually embedded in an application message.
4.1 What can be bypassed in an OPES Flow? The current specification does not provide for a good mechanism that
allow and "end" to specify to "bypass this service but only if it is
a part of that OPES system" or "bypass all services of that OPES
system but not of this OPES system". Furthermore, if an OPES
processor does not know for sure that a bypass URI does not match its
service, it must bypass that service.
If no non-OPES content is available without the specified service,
the bypass request for that service must be ignored. This design
implies that it may not be possible to detect non-OPES content
existence or to detect violations of bypass rules in the environments
where the tester does not know whether non-OPES content exists. This
design assumes that most bypass requests are intended for situations
where serving undesirable OPES content is better than serving an
error message that no preferred non-OPES content exists.
4.1 Bypassable entities
In this work, the focus is on developing a bypass feature that allow In this work, the focus is on developing a bypass feature that allow
a user to instruct the OPES System to bypass some or all of its a user to instruct the OPES System to bypass some or all of its
services. The collection of OPES services that can be bypassed is a services. The collection of OPES services that can be bypassed is a
function of the agreement of the OPES provider with either (or both) function of the agreement of the OPES provider with either (or both)
the content provider or the content consumer applications. In the the content provider or the content consumer applications. In the
general case, a bypass request is viewed as a bypass instruction that general case, a bypass request is viewed as a bypass instruction that
contains a URI that identifies an OPES entity or a group of OPES contains a URI that identifies an OPES entity or a group of OPES
entities that perform a service (or services) to be bypassed. An entities that perform a service (or services) to be bypassed. An
instruction may contain more than one such URI. A special wildcard instruction may contain more than one such URI. A special wildcard
identifier can be used to represent all possible URIs (i.e., all identifier can be used to represent all possible URIs.
possible OPES services that are relevant to an OPES processor).
In an OPES Flow, a bypass request is processed in a local manner by In an OPES Flow, a bypass request is processed by each involved OPES
each involved OPES processor. This means that an OPES processor processor. This means that an OPES processor examines the bypass
examines the bypass instruction and if non-OPES content is available, instruction and if non-OPES content is available, the processor then
the processor then bypasses services that are local to itself. This bypasses the indicated services. The request is then forwarded to the
may include the act of bypassing itself completely depending on what next OPES processor in the OPES Flow. The next OPES processor would
is specified in the URI. The request is then forwarded to the next then handle all bypass requests, regardless of the previous processor
OPES processor in the OPES Flow. The next OPES processor would then actions. The processing chain continues throughout the whole
honor all bypass requests that are relevant to it provided that the processors that are involved in the OPES Flow.
non-OPES content is available. The processing chain continues
throughout the whole processors that are involved in the OPES Flow.
If an OPES processor does not know how to honor a bypass request it
forwards the message to the next processor in the OPES Flow. At the
OPES system level, a bypass instruction is honored when at least one
OPES processor bypasses the services that are specified by the URI
that is specified in the instruction (provided that the non-OPES
content is available).
4.2 Bypass requirements for OPES System 4.2 System requirements
In an OPES System bypass requests are generally client centric and go In an OPES System bypass requests are generally client centric
in the opposite direction of tracing requests. Bypass can be (originated by the data consumer application) and go in the opposite
performed out of band or in-band. This work requires that the Bypass direction of tracing requests. This work requires that the bypass
feature be performed in-band as an extension to an application feature be performed in-band as an extension to an application
specific protocol. Non-OPES entities should be able to safely ignore specific protocol. Non-OPES entities should be able to safely ignore
these extensions. The work does not prevent OPES Systems from these extensions. The work does not prevent OPES Systems from
developing their own out of band protocols. developing their own out of band protocols.
The following requirements apply for Bypass feature as related to an The following requirements apply for bypass feature as related to an
OPES System (the availability of a non-OPES content is a OPES System (the availability of a non-OPES content is a
precondition) : precondition) :
o An OPES system MUST support a Bypass feature. This means that the 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 OPES System bypasses services whose URIs are identified by an OPES
end (usually data consumer application). "end".
o An OPES System MUST provide OPES version of the content if
non-OPES version is not available.
In order to facilitate the debugging (or data consumer user In order to facilitate the debugging (or data consumer user
experience) of the bypass feature in an OPES System, it would be experience) of the bypass feature in an OPES System, it would be
beneficial if non-bypassed entities include information related to beneficial if non-bypassed entities include information related to
why they ignored the bypass instruction. It is important to note that why they ignored the bypass instruction. It is important to note that
in some cases the tracing facility itself may be broken and the whole in some cases the tracing facility itself may be broken and the whole
OPES System (or part) may need to be bypassed through the issue of a OPES System (or part) may need to be bypassed through the issue of a
bypass instruction. bypass instruction.
4.3 Bypass requirements for OPES processors 4.3 Processor requirements
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 bypass
request. In some cases, the first OPES processor that will get the
bypass request may not be the first OPES processor that will know
whether a non-OPES version of the content is available or not.
Bypass requirements for OPES processors are (the availability of a Bypass requirements for OPES processors are (the availability of a
non-OPES content is a precondition): non-OPES content is a precondition):
o OPES processor SHOULD be able to interpret and process a bypass o OPES processor SHOULD be able to interpret and process a bypass
instruction. This requirement applies to all bypass instructions, instruction. This requirement applies to all bypass instructions,
including those that identify known-to-recipient services. including those that identify unknown-to-recipient services.
o OPES processors that do not know how to process a bypass request o OPES processors MUST forward bypass request to the next
MUST forward the request to the next application hop provided that application hop provided that the next hop speaks application
the next hop speaks application protocol with OPES bypass support. protocol with OPES bypass support.
o OPES processor SHOULD be able to bypass it's service(s) execution. o OPES processor SHOULD be able to bypass it's service(s) execution.
Provided that non-OPES content is available, those OPES processors OPES processors that know how to process and interpret a bypass
that know how to process and interpret a bypass instruction have the instruction have the following requirements:
following requirements:
o The recipient of a bypass instruction with a URI that does not 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 identify any known-to-recipient OPES entity MUST treat that URI as
a wildcard identifier (meaning bypass all applicable local a wildcard identifier (meaning bypass all applicable services).
services).
4.4 Bypass requirements for callout servers 4.4 Callout server requirements
In an OPES system, it is the task of an OPES processor to process In an OPES system, it is the task of an OPES processor to process
bypass requests. However, in some cases, callout servers may be bypass requests. The OPES System administrator decides if and under
involved in processing Bypass requests. This should be done under the what conditions callout servers process bypass requests.
control of the OPES System provider.
5. Protocol Binding 5. Protocol Binding
The task of encoding tracing and bypass features is application The task of encoding tracing and bypass features is application
protocol specific. Separate documents will address HTTP and other protocol specific. Separate documents will address HTTP and other
protocols. protocols. These documents must address the ordering of trace
information if needed.
6. Compliance Considerations 6. Compliance Considerations
This work specifies high level requirements for tracing and bypass. This specification defines compliance for the following compliance
Protocol binding specifications MUST consider and follow all MUSTs in subjects: OPES System, processors, entities and callout servers.
this draft. Protocol binding specifications MUST be compliant to this
draft. As such any implementation compliant to the binding A compliance subject is compliant if it satisfies all applicable
specification is also compliant to this draft. "MUST" and "SHOULD" level requirements. By definition, to satisfy a
"MUST" level requirement means to act as prescribed by the
requirement; to satisfy a "SHOULD" level requirement means to either
act as prescribed by the requirement or have a reason to act
differently. A requirement is applicable to the subject if it
instructs (addresses) the subject.
Informally, compliance with this draft means that there are no known
"MUST" violations, and all "SHOULD" violations are conscious. In
other words, a "SHOULD" means "MUST satisfy or MUST have a reason to
violate". It is expected that compliance claims are accompanied by a
list of unsupported SHOULDs (if any), in an appropriate format,
explaining why preferred behavior was not chosen.
Only normative parts of this specification affect compliance.
Normative parts are: parts explicitly marked using the word
"normative", definitions, and phrases containing unquoted capitalized
keywords from [RFC2119]. Consequently, examples and illustrations are
not normative.
7. IANA considerations 7. IANA considerations
This specification contains no IANA considerations. Application This specification contains no IANA considerations. Application
bindings MAY contain application-specific IANA considerations. bindings MAY contain application-specific IANA considerations.
8. Security Considerations 8. Security Considerations
The security considerations for OPES are documented in [7]. This The security considerations for OPES are documented in [8]. This
document is a requirement document for tracing and Bypass feature. document is a requirement document for tracing and bypass feature.
The requirements that are stated in this document can be used to The requirements that are stated in this document can be used to
extend an application level protocol to support these features. As extend an application level protocol to support these features. As
such, the work has security precautions. such, the work has security precautions.
8.1 Tracing security considerations 8.1 Tracing security considerations
The tracing facility for OPES architecture is implemented as a The tracing facility for OPES architecture is implemented as a
protocol extension. Inadequate implementations of the tracing protocol extension. Inadequate implementations of the tracing
facility may defeat safeguards built into the OPES architecture. The facility may defeat safeguards built into the OPES architecture. The
tracing facility by itself can become a target of malicious attacks tracing facility by itself can become a target of malicious attacks
skipping to change at page 15, line 11 skipping to change at page 15, line 11
can overwhelm a data consumer application or an OPES entity in an can overwhelm a data consumer application or an OPES entity in an
OPES Flow. Inserting wrong tracing information can complicates the OPES Flow. Inserting wrong tracing information can complicates the
debugging tasks performed by system administrator during trouble debugging tasks performed by system administrator during trouble
shooting of OPES System behavior. shooting of OPES System behavior.
As a precaution, OPES entities ought to be capable of verifying that As a precaution, OPES entities ought to be capable of verifying that
the inserted traces are performed by legal OPES entities. This can be the inserted traces are performed by legal OPES entities. This can be
done as part of the authorization and authentication face. Policy can done as part of the authorization and authentication face. Policy can
be used to indicate what trace information can be expected from a be used to indicate what trace information can be expected from a
peer entity. Other application level related security concerns can be peer entity. Other application level related security concerns can be
found in [7]. found in [8].
8.2 Bypass security considerations 8.2 Bypass security considerations
The bypass facility for OPES architecture is implemented as a The bypass facility for OPES architecture is implemented as a
protocol extension. Inadequate implementations of the bypass facility protocol extension. Inadequate implementations of the bypass facility
may defeat safeguards built into the OPES architecture. The bypass may defeat safeguards built into the OPES architecture. The bypass
facility by itself can become a target of malicious attacks or used facility by itself can become a target of malicious attacks or used
to lunch attacks on an OPES System. to lunch attacks on an OPES System.
Threats caused by or against the bypass facility can be viewed as Threats caused by or against the bypass facility can be viewed as
skipping to change at page 16, line 29 skipping to change at page 16, line 29
Tap bypass can also be a threat. This is because systems implementing Tap bypass can also be a threat. This is because systems implementing
wiretaps via OPES entities may be incorrectly configured to honor wiretaps via OPES entities may be incorrectly configured to honor
bypass and, hence, ignore (leave undetected) traffic with bypass bypass and, hence, ignore (leave undetected) traffic with bypass
instructions that should have been tapped or logged. It is also instructions that should have been tapped or logged. It is also
possible for one end to bypass services such as virus scanning at the possible for one end to bypass services such as virus scanning at the
receiving end. This threat can be used by hackers to inject viruses receiving end. This threat can be used by hackers to inject viruses
throughout the network. throughout the network.
Other application level related security concerns can be found in Other application level related security concerns can be found in
[7]. [8].
Normative References Normative References
[1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", [1] A. Barbir et al., "An Architecture for Open Pluggable Edge
Internet-Draft http://www.ietf.org/internet-drafts/ Services (OPES)", Internet-Draft http://www.ietf.org/
draft-ietf-opes-scenarios-01.txt, August 2002. internet-drafts/draft-ietf-opes-architecture-04, December 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
Informative References Informative References
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy [3] A. Barbir et al., "OPES Use Cases and Deployment Scenarios",
Internet-Draft http://www.ietf.org/internet-drafts/
draft-ietf-opes-scenarios-01.txt, August 2002.
[4] 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] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Levels", RFC 2119, March 1997.
[4] 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.
[5] A. Barbir et al., "Policy, Authorization and Enforcement [6] 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.
[6] Rousskov, A. et al, "HTTP adaptation with OPES", Internet-Draft [7] Rousskov, A. et al, "HTTP adaptation with OPES", Internet-Draft
http://www.ietf.org/internet-drafts/draft-ietf-opes-http-00.txt, http://www.ietf.org/internet-drafts/draft-ietf-opes-http-01.txt,
July 2003. October 2003.
[7] A. Barbir et al., "Security Threats and Risks for Open Pluggable [8] 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
Services (OPES)", Internet-Draft http://www.ietf.org/
internet-drafts/draft-ietf-opes-architecture-04, December 2002.
[9] A. Barbir et al., "OPES Treatment of IAB Considerations", [9] 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-02.txt, September 2003. draft-ietf-opes-iab-03.txt, October 2003.
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/