draft-ietf-opes-end-comm-08.txt   rfc3897.txt 
Open Pluggable Edge Services A. Barbir Network Working Group A. Barbir
Internet-Draft Nortel Networks Request for Comments: 3897 Nortel Networks
Expires: November 4, 2004 May 6, 2004 Category: Informational September 2004
OPES entities and end points communication Open Pluggable Edge Services (OPES) Entities
draft-ietf-opes-end-comm-08 and End Points Communication
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 4, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 2
2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Tracing Requirements . . . . . . . . . . . . . . . . . . . . . 5 3. Tracing Requirements . . . . . . . . . . . . . . . . . . . . . 3
3.1 Traceable entities . . . . . . . . . . . . . . . . . . . . 5 3.1. Traceable entities . . . . . . . . . . . . . . . . . . . 3
3.2 System requirements . . . . . . . . . . . . . . . . . . . 6 3.2. System requirements . . . . . . . . . . . . . . . . . . 5
3.3 Processor requirements . . . . . . . . . . . . . . . . . . 6 3.3. Processor requirements . . . . . . . . . . . . . . . . . 5
3.4 Callout server requirements . . . . . . . . . . . . . . . 7 3.4. Callout server requirements . . . . . . . . . . . . . . 5
4. Bypass (Non-blocking feature) Requirements . . . . . . . . . . 8 4. Bypass (Non-blocking feature) Requirements . . . . . . . . . . 6
4.1 Bypassable entities . . . . . . . . . . . . . . . . . . . 9 4.1. Bypassable entities . . . . . . . . . . . . . . . . . . 7
4.2 System requirements . . . . . . . . . . . . . . . . . . . 9 4.2. System requirements . . . . . . . . . . . . . . . . . . 8
4.3 Processor requirements . . . . . . . . . . . . . . . . . . 10 4.3. Processor requirements . . . . . . . . . . . . . . . . . 8
4.4 Callout server requirements . . . . . . . . . . . . . . . 10 4.4. Callout server requirements . . . . . . . . . . . . . . 9
5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 9
6. Compliance Considerations . . . . . . . . . . . . . . . . . . 12 6. Compliance Considerations . . . . . . . . . . . . . . . . . . 9
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1 Tracing security considerations . . . . . . . . . . . . . 14 8.1. Tracing security considerations . . . . . . . . . . . . 10
8.2 Bypass security considerations . . . . . . . . . . . . . . 15 8.2. Bypass security considerations . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2 Informative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 20 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Open Pluggable Edge Services (OPES) architecture [1] 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 OPES tracing and bypass functionality. The This work specifies OPES tracing and bypass functionality. The
architecture document [1] requires that tracing is supported in-band. architecture document [1] requires that tracing is supported in-band.
This design goal limits the type of application protocols that OPES This design goal limits the type of application protocols that OPES
can support. The details of what a trace record can convey are also can support. The details of what a trace record can convey are also
dependent on the choice of the application level protocol. For these dependent on the choice of the application level protocol. For these
reasons, this work only documents requirements for OPES entities that reasons, this work only documents requirements for OPES entities that
are needed to support traces and bypass functionality. The task of are needed to support traces and bypass functionality. The task of
encoding tracing and bypass features is application protocol encoding tracing and bypass features is application protocol
specific. Separate documents will address HTTP and other protocols. specific. Separate documents will address HTTP and other protocols.
The architecture does not prevent implementers from developing The architecture does not prevent implementers from developing out-
out-of-band protocols and techniques to address tracing and bypass. of-band protocols and techniques to address tracing and bypass. Such
Such protocols are out of scope of the current work. protocols are out of scope of the current work.
1.1 Terminology 1.1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. When document are to be interpreted as described in BCP 14, RFC 2119 [2].
used with the normative meanings, these keywords will be all When used with the normative meanings, these keywords will be all
uppercase. Occurrences of these words in lowercase comprise normal uppercase. Occurrences of these words in lowercase comprise normal
prose usage, with no normative implications. 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 section provides a definition of OPES System. This is needed in
order to define what is traceable (or bypassable) 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 authorized Definition: An OPES System is a set of all OPES entities authorized
by either the data provider or the data consumer application to by either the data provider or the data consumer 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).
skipping to change at page 4, line 40 skipping to change at page 3, line 27
process the same message several times. process the same message several times.
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,
the CDN uses to adapt and deliver the image comprise an OPES System. which the CDN uses to adapt and deliver the image, comprise an OPES
In a more complex example, an OPES System would contain third party System. In a more complex example, an OPES System would contain
OPES entities that the CDN engages to perform adaptations (e.g., to third party OPES entities that the CDN engages to perform adaptations
adjust image quality). (e.g., to adjust image quality).
3. Tracing Requirements 3. Tracing Requirements
The definition of OPES trace and tracing are given next. The definition of OPES trace and tracing are given next.
OPES trace: application message information about OPES entities OPES trace: application message information about OPES entities
that adapted the message. that adapted the message.
OPES tracing: the process of creating, manipulating, or OPES tracing: the process of creating, manipulating, or
interpreting an OPES trace. interpreting an OPES trace.
Note that the above trace definition assumes in-band tracing. This Note that the above trace definition assumes in-band tracing. This
dependency can be removed if desired. Tracing is performed on per dependency can be removed if desired. Tracing is performed on per
message basis. Trace format is dependent on the application protocol message basis. Trace format is dependent on the application protocol
that is being adapted. A traceable entity can appear multiple times that is being adapted. A traceable entity can appear multiple times
in a trace (for example, every time it acts on a message). in a trace (for example, every time it acts on a message).
3.1 Traceable entities 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 an "end" with information about OPES Tracing information provides an "end" with information about OPES
entities that adapted the data. There are two distinct uses of OPES entities that adapted the data. There are two distinct uses of OPES
traces. First, a trace enables an "end" to detect the presence of traces. First, a trace enables an "end" to detect the presence of
OPES System. Such "end" should be able to see a trace entry, but does OPES System. Such "end" should be able to see a trace entry, but
not need to be able to interpret it beyond identification of the OPES does not need to be able to interpret it beyond identification of the
System and location of certain required OPES-related disclosures (see OPES System and location of certain required OPES-related disclosures
Section 3.2). (see 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" without interpretation, as opaque data the administrator by an "end" without interpretation, as opaque data
(e.g., a TCP packet or an HTTP message snapshot). The administrator (e.g., a TCP packet or an HTTP message snapshot). The administrator
can use the trace information to identify the participating OPES can use the trace information to identify the participating OPES
entities. The administrator can use the trace to identify the applied entities. The administrator can use the trace to identify the
adaptation services along with other message-specific information. 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 require the freedom in what to put ways of looking into tracing, they require the freedom in what to put
in trace records and how to format them. in trace records and how to format them.
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 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 of information in a trace can be OPES System specific or can be
skipping to change at page 6, line 4 skipping to change at page 4, line 35
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 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 of information in a trace can be OPES System specific or can be
defined by application bindings documents. 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 System 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 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
processor for adding System entries; an OPES processor can use a OPES processor for adding System entries; an OPES processor can
callout service to manage all OPES trace manipulations (since such use a callout service to manage all OPES trace manipulations
manipulations are OPES adaptations). (since such 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 decode trace details and to resolve the problems. of the operator to decode trace details and to resolve the problems.
3.2 System requirements 3.2 System requirements
The following requirements document actions when forming an OPES The following requirements document actions when forming an OPES
skipping to change at page 6, line 49 skipping to change at page 5, line 36
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 reference validity or technical policy, policy enforcement, or reference validity or technical
contact and contains no requirements regarding encoding, language, contact and contains no requirements regarding encoding, language,
format, or any other aspects of that information. For example, a URI format, or any other aspects of that information. For example, a URI
used for an OPES System trace entry may look like "http:// used for an OPES System trace entry may look like "http://
www.examplecompany.com/opes/?client=example.com" where the identified www.examplecompany.com/opes/?client=example.com" where the identified
web page is dynamically generated and contains the all OPES System web page is dynamically generated and contains the all OPES System
information required above. information required above.
3.3 Processor requirements 3.3. Processor requirements
The following requirements document actions when forming an OPES The following requirements document actions when forming an OPES
System trace entry: System trace entry:
o OPES processor SHOULD 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.
3.4 Callout server requirements 3.4. Callout server requirements
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. The OPES System administrator records to application messages. The OPES System administrator
decides if and under what conditions callout servers may add trace decides if and under what conditions callout servers may add trace
information to application messages. information to application messages.
4. Bypass (Non-blocking feature) Requirements 4. Bypass (Non-blocking feature) Requirements
IAB recommendation (3.3) [6] requires that the OPES architecture does IAB recommendation (3.3) [6] 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
constitutes non-OPES content. In this work the definition of constitutes non-OPES content. In this work the definition of "non-
"non-OPES" content is provider dependent. In some cases, the OPES" content is provider dependent. In some cases, the availability
availability of "non-OPES" content can be a function of the internal of "non-OPES" content can be a function of the internal policy of a
policy of a given organization that has contracted the services of an given organization that has contracted the services of an OPES
OPES provider. For example, Company A has as contract with an OPES provider. For example, Company A has as contract with an OPES
provider to perform virus checking on all e-mail attachments. An provider to perform virus checking on all e-mail attachments. An
employee X of Company A can issue a non-blocking request for the employee X of Company A can issue a non-blocking request for the
virus scanning service. The request could be ignored by the OPES virus scanning service. The request could be ignored by the OPES
provider since it contradicts its agreement with Company A. provider since it contradicts its agreement with Company A.
The availability of non-OPES content can be a function of content The availability of non-OPES content can be a function of content
providers (or consumers or both) policy and deployment scenarios [5]. providers (or consumers or both) policy and deployment scenarios [5].
For this reason, this work does not attempt to define what is an OPES 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 content as opposed to non-OPES content. The meaning of OPES versus
non-OPES content is assumed to be determined through various non-OPES content is assumed to be determined through various
agreements between the OPES provider, data provider and/or data agreements between the OPES provider, data provider and/or data
consumer. The agreement determines what OPES services can be bypassed consumer. The agreement determines what OPES services can be
and in what order (if applicable). bypassed and in what order (if applicable).
This specification documents bypassing of an OPES service or a group This specification documents bypassing of an OPES service or a group
of services identified by a URI. In this context, to "bypass the of services identified by a URI. In this context, to "bypass the
service" for a given application message in an OPES Flow means to service" for a given application message in an OPES Flow means to
"not invoke the service" for that application message. A bypass URI "not invoke the service" for that application message. A bypass URI
that identifies an OPES system (processor) matches all services that identifies an OPES system (processor) matches all services
attached to that OPES system (processor). However, bypassing of OPES attached to that OPES system (processor). However, bypassing of OPES
processors and OPES Systems themselves requires non-OPES mechanisms processors and OPES Systems themselves requires non-OPES mechanisms
and is out of this specification scope. A bypass request an and is out of this specification scope. A bypass request an
instruction to bypass, usually embedded in an application message. instruction to bypass, usually embedded in an application message.
skipping to change at page 9, line 19 skipping to change at page 7, line 22
error message that no preferred non-OPES content exists. error message that no preferred non-OPES content exists.
Bypass feature is to malfunctioning OPES services as HTTP "reload" Bypass feature is to malfunctioning OPES services as HTTP "reload"
request is to malfunctioning HTTP caches. The primary purpose of the request is to malfunctioning HTTP caches. The primary purpose of the
bypass is to get usable content in the presence of service failures bypass is to get usable content in the presence of service failures
and not to provide the content consumer with more information on what and not to provide the content consumer with more information on what
is going on. OPES trace should be used for the latter instead. is going on. OPES trace should be used for the latter instead.
While this work defines a "bypass service if possible" feature, there While this work defines a "bypass service if possible" feature, there
are other related bypass features that can be implemented in OPES are other related bypass features that can be implemented in OPES
and/or in application protocols being adapted. For example, a "bypass and/or in application protocols being adapted. For example, a
service or generate an error" or "bypass OPES entity or generate an "bypass service or generate an error" or "bypass OPES entity or
error". Such services would be useful for debugging broken OPES generate an error". Such services would be useful for debugging
systems and may be defined in other OPES specifications. This work broken OPES systems and may be defined in other OPES specifications.
concentrates on documenting a user-level bypass feature addressing This work concentrates on documenting a user-level bypass feature
direct IAB concerns. addressing direct IAB concerns.
4.1 Bypassable entities 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 allows
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. identifier can be used to represent all possible URIs.
In an OPES Flow, a bypass request is processed by each involved OPES In an OPES Flow, a bypass request is processed by each involved OPES
processor. This means that an OPES processor examines the bypass processor. This means that an OPES processor examines the bypass
instruction and if non-OPES content is available, the processor then instruction and if non-OPES content is available, the processor then
bypasses the indicated services. The request is then forwarded to the bypasses the indicated services. The request is then forwarded to
next OPES processor in the OPES Flow. The next OPES processor would the next OPES processor in the OPES Flow. The next OPES processor
then handle all bypass requests, regardless of the previous processor would then handle all bypass requests, regardless of the previous
actions. The processing chain continues throughout the whole processor actions. The processing chain continues throughout the
processors that are involved in the OPES Flow. whole processors that are involved in the OPES Flow.
4.2 System requirements 4.2. System requirements
In an OPES System bypass requests are generally client centric In an OPES System, bypass requests are generally client centric
(originated by the data consumer application) and go in the opposite (originated by the data consumer application) and go in the opposite
direction of tracing requests. 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) :
skipping to change at page 10, line 13 skipping to change at page 8, line 18
(originated by the data consumer application) and go in the opposite (originated by the data consumer application) and go in the opposite
direction of tracing requests. 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 services whose URIs are identified by an OPES OPES System bypasses services whose URIs are identified by an OPES
"end". "end".
o An OPES System MUST provide OPES version of the content if o An OPES System MUST provide OPES version of the content if non-
non-OPES version is not available. 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 included 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
in some cases the tracing facility itself may be broken and the whole that in some cases the tracing facility itself may be broken and the
OPES System (or part) may need to be bypassed through the issue of a whole OPES System (or part) may need to be bypassed through the issue
bypass instruction. of a bypass instruction.
4.3 Processor requirements 4.3. Processor requirements
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 unknown-to-recipient services. including those that identify unknown-to-recipient services.
o OPES processors MUST forward bypass request to the next o OPES processors MUST forward bypass request to the next
application hop provided that the next hop speaks application application hop provided that 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.
OPES processors that know how to process and interpret a bypass OPES processors that know how to process and interpret a bypass
instruction have the following requirements: instruction have the following requirements:
skipping to change at page 10, line 41 skipping to change at page 8, line 48
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 unknown-to-recipient services. including those that identify unknown-to-recipient services.
o OPES processors MUST forward bypass request to the next o OPES processors MUST forward bypass request to the next
application hop provided that the next hop speaks application application hop provided that 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.
OPES processors that know how to process and interpret a bypass OPES processors that know how to process and interpret a bypass
instruction have the following requirements: instruction have the 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 services). a wildcard identifier (meaning bypass all applicable services).
4.4 Callout server requirements 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. The OPES System administrator decides if and under bypass requests. The OPES System administrator decides if and under
what conditions callout servers process bypass requests. what conditions callout servers process bypass requests.
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. These documents must address the ordering of trace protocols. These documents must address the ordering of trace
information if needed. information as needed.
6. Compliance Considerations 6. Compliance Considerations
This specification defines compliance for the following compliance This specification defines compliance for the following compliance
subjects: OPES System, processors, entities and callout servers. subjects: OPES System, processors, entities and callout servers.
A compliance subject is compliant if it satisfies all applicable A compliance subject is compliant if it satisfies all applicable
"MUST" and "SHOULD" level requirements. By definition, to satisfy a "MUST" and "SHOULD" level requirements. By definition, to satisfy a
"MUST" level requirement means to act as prescribed by the "MUST" level requirement means to act as prescribed by the
requirement; to satisfy a "SHOULD" level requirement means to either requirement; to satisfy a "SHOULD" level requirement means to either
act as prescribed by the requirement or have a reason to act act as prescribed by the requirement or have a reason to act
differently. A requirement is applicable to the subject if it differently. A requirement is applicable to the subject if it
instructs (addresses) the subject. instructs (addresses) the subject.
Informally, compliance with this draft means that there are no known Informally, compliance with this document means that there are no
"MUST" violations, and all "SHOULD" violations are conscious. In known "MUST" violations, and all "SHOULD" violations are conscious.
other words, a "SHOULD" means "MUST satisfy or MUST have a reason to In other words, a "SHOULD" means "MUST satisfy or MUST have a reason
violate". It is expected that compliance claims are accompanied by a to violate". It is expected that compliance claims are accompanied
list of unsupported SHOULDs (if any), in an appropriate format, by a list of unsupported SHOULDs (if any), in an appropriate format,
explaining why preferred behavior was not chosen. explaining why preferred behavior was not chosen.
Only normative parts of this specification affect compliance. Only normative parts of this specification affect compliance.
Normative parts are: parts explicitly marked using the word Normative parts are: parts explicitly marked using the word
"normative", definitions, and phrases containing unquoted capitalized "normative", definitions, and phrases containing unquoted capitalized
keywords from [RFC2119]. Consequently, examples and illustrations are keywords from RFC 2119 [2]. Consequently, examples and illustrations
not normative. 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
Security considerations for OPES are documented in [4]. Policy and Security considerations for OPES are documented in [4]. Policy and
authorization issues are documented in [3]. It is recommended that authorization issues are documented in [3]. It is recommended that
designers consult these documents before reading this section. designers consult these documents before reading this section.
This document is a requirement document for tracing and bypass This document is a requirement document for tracing and bypass
feature. The requirements that are stated in this document can be feature. The requirements that are stated in this document can be
used to extend an application level protocol to support these used to extend an application level protocol to support these
features. As such, the work has security precautions. features. As 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
or used to lunch attacks on an OPES System. or used to lunch attacks on an OPES System.
Threats caused by or against the tracing facility can be viewed as 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 at the application level in an OPES Flow. In this case, the
threats can affect the data consumer and the data provider threats can affect the data consumer and the data provider
skipping to change at page 14, line 38 skipping to change at page 10, line 38
Since tracing information is a protocol extension, these traces can Since tracing information is a protocol extension, these traces can
be injected in the data flow by non-OPES entities. In this case, be injected in the data flow by non-OPES entities. In this case,
there are risks that non-OPES entities can be compromised in a there are risks that non-OPES entities can be compromised in a
fashion that threat the overall integrity and effectiveness of an fashion that threat the overall integrity and effectiveness of an
OPES System. For example, a non-OPES proxy can add fake tracing 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 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 unwanted, or non existent services. A non-OPES entity can inject
large size traces that may cause buffer overflow in a data consumer large size traces that may cause buffer overflow in a data consumer
application. The same threats can arise from compromised OPES application. The same threats can arise from compromised OPES
entities. An attacker can control an OPES entity and inject wrong, or entities. An attacker can control an OPES entity and inject wrong,
very large trace information that can overwhelm an end or the next 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 OPES entity in an OPES flow. Similar threats can result from bad
implementations of the tracing facility in trusted OPES entities. implementations of the tracing facility in trusted OPES entities.
Compromised tracing information can be used to launch attacks on an Compromised tracing information can be used to launch attacks on an
OPES System that give the impression that unwanted content OPES System that give the impression that unwanted content
transformation was performed on the data. This can be achieved by transformation was performed on the data. This can be achieved by
inserting wrong entity (such OPES processor) identifiers. A inserting wrong entity (such OPES processor) identifiers. A
compromised trace can affect the overall message integrity structure. compromised trace can affect the overall message integrity structure.
This can affect entities that use message header information to This can affect entities that use message header information to
perform services such as accounting, load balancing, or perform services such as accounting, load balancing, or reference-
reference-based services. based services.
Compromised trace information can be used to launch DoS attacks that Compromised trace information can be used to launch DoS attacks that
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 complicate 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
done as part of the authorization and authentication face. Policy can be done as part of the authorization and authentication face. Policy
be used to indicate what trace information can be expected from a can 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
found in [4]. be found in [4].
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
may defeat safeguards built into the OPES architecture. The bypass facility may defeat safeguards built into the OPES architecture. The
facility by itself can become a target of malicious attacks or used bypass facility by itself can become a target of malicious attacks or
to lunch attacks on an OPES System. used 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
threats at the application level in an OPES Flow. In this case, the threats at the application level in an OPES Flow. In this case, the
threats can affect the data consumer and the data provider threats can affect the data consumer and the data provider
application. application.
There are risks for the OPES System by non-OPES entities, whereby, There are risks for the OPES System by non-OPES entities, whereby,
these entities can insert bypass instructions into the OPES Flow. The these entities can insert bypass instructions into the OPES Flow.
threat can come from compromised non-OPES entities. The threat might The threat can come from compromised non-OPES entities. The threat
affect the overall integrity and effectiveness of an OPES System. For might affect the overall integrity and effectiveness of an OPES
example, a non-OPES proxy can add bypass instruction to bypass System. For example, a non-OPES proxy can add bypass instruction to
legitimate OPES entities. The attack might result in overwhelming the bypass legitimate OPES entities. The attack might result in
original content provider servers, since the attack essentially overwhelming the original content provider servers, since the attack
bypass any load balancing techniques. In addition, such an attack is essentially bypass any load balancing techniques. In addition, such
also equivalent to a DoS attack, whereby, a legitimate data consumer an attack is also equivalent to a DoS attack, whereby, a legitimate
application may not be able to access some content from a content data consumer application may not be able to access some content from
provider or its OPES version. a content provider or its OPES version.
Since an OPES Flow may include non-OPES entities, it is susceptible Since an OPES Flow may include non-OPES entities, it is susceptible
to man-in-the-middle attacks, whereby an intruder may inject bypass to man-in-the-middle attacks, whereby an intruder may inject bypass
instructions into the data path. These attacks may affect content instructions into the data path. These attacks may affect content
availability or disturb load balancing techniques in the network. availability or disturb load balancing techniques in the network.
The above threats can also arise by compromised OPES entities. An The above threats can also arise by compromised OPES entities. An
intruder can compromise an OPES entities and then use intruder can compromise an OPES entities and then use man-in-the-
man-in-the-middle techniques to disturb content availability to a middle techniques to disturb content availability to a data consumer
data consumer application or overload a content provider server application or overload a content provider server (essentially, some
(essentially, some form of a DoS attack). form of a DoS attack).
Attackers can use the bypass instruction to affect the overall Attackers can use the bypass instruction to affect the overall
integrity of the OPES System. The ability to introduce bypass integrity of the OPES System. The ability to introduce bypass
instructions into a data flow may effect the accounting of the OPES instructions into a data flow may effect the accounting of the OPES
System. It may also affect the quality of content that is delivered System. It may also affect the quality of content that is delivered
to the data consumer applications. Similar threats can arise from bad to the data consumer applications. Similar threats can arise from
implementations of the bypass facility. bad implementations of the bypass facility.
Inconsistent or selective bypass is also a threat. Here, one end can Inconsistent or selective bypass is also a threat. Here, one end can
try to bypass a subset of OPES entities so that the resulting content try to bypass a subset of OPES entities so that the resulting content
is malformed and crashes or compromises entities that process that is malformed and crashes or compromises entities that process that
content (and expect that content to be complete and valid). Such content (and expect that content to be complete and valid). Such
exceptions are often not tested because implementers do not expect a exceptions are often not tested because implementers do not expect a
vital service to disappear from the processing loop. vital service to disappear from the processing loop.
Other threats can arise from configuring access control policies for Other threats can arise from configuring access control policies for
OPES entities. It is possible that systems implementing access OPES entities. It is possible that systems implementing access
controls via OPES entities may be incorrectly configured to honor controls via OPES entities may be incorrectly configured to honor
bypass and, hence, give unauthorized access to intruders. bypass and, hence, give unauthorized access to intruders.
Tap bypass can also be a threat. This is because systems implementing Tap bypass can also be a threat. This is because systems
wiretaps via OPES entities may be incorrectly configured to honor implementing wiretaps via OPES entities may be incorrectly configured
bypass and, hence, ignore (leave undetected) traffic with bypass to honor bypass and, hence, ignore (leave undetected) traffic with
instructions that should have been tapped or logged. It is also bypass instructions that should have been tapped or logged. It is
possible for one end to bypass services such as virus scanning at the also possible for one end to bypass services such as virus scanning
receiving end. This threat can be used by hackers to inject viruses at the receiving end. This threat can be used by hackers to inject
throughout the network. Following an IETF policy on Wiretapping [7], viruses throughout the network. Following an IETF policy on
OPES communication model does not consider wiretapping requirements. Wiretapping [7], OPES communication model does not consider
Nevertheless, the documented threat is real, not obvious, and OPES wiretapping requirements. Nevertheless, the documented threat is
technology users operating in wiretapping or similar logging real, not obvious, and OPES technology users operating in wiretapping
environments should be aware of it. or similar logging environments should be aware of it.
Other application level related security concerns can be found in Other application level related security concerns can be found in
[4]. [4].
9. References 9. References
9.1 Normative References 9.1. Normative References
[1] A. Barbir et al., "An Architecture for Open Pluggable Edge [1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An
Services (OPES)", Internet-Draft http://www.ietf.org/ Architecture for Open Pluggable Edge Services (OPES)", RFC 3835,
internet-drafts/draft-ietf-opes-architecture-04, December 2002. August 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] A. Barbir et al., "Policy, Authorization and Enforcement [3] Barbir, A., Batuner, O., Beck, A., Chan, T., and H. Orman,
Requirements of OPES", Internet-Draft http://www.ietf.org/ "Policy, Authorization, and Enforcement Requirements of Open
internet-drafts/draft-ietf-opes-authorization-02.txt, February Pluggable Edge Services (OPES)", RFC 3838, August 2004.
2003.
[4] A. Barbir et al., "Security Threats and Risks for Open Pluggable [4] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H.
Edge Services", Internet-Draft http://www.ietf.org/ Orman, "Security Threats and Risks for Open Pluggable Edge
internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. Services (OPES)", RFC 3837, August 2004.
9.2 Informative References 9.2 Informative References
[5] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", [5] Barbir A., Burger, E., Chen, R., McHenry, S., Orman, H., and R.
Internet-Draft http://www.ietf.org/internet-drafts/ Penno, "Open Pluggable Edge Services (OPES) Use Cases and
draft-ietf-opes-scenarios-01.txt, August 2002. Deployment Scenarios", RFC 3752, April 2004.
[6] Floyd, S. and L. Daigle, "IAB Architectural and Policy [6] 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.
[7] IAB, IESG., "IETF Policy on Wiretapping", RFC 2804, May 2000. [7] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[8] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[9] Rousskov, A. et al, "HTTP adaptation with OPES", Internet-Draft 10. Acknowledgements
http://www.ietf.org/internet-drafts/
draft-ietf-opes-http-01.txt, October 2003.
[10] A. Barbir et al., "OPES Treatment of IAB Considerations", Several people has contributed to this work. Many thanks to: Alex
Internet-Draft http://www.ietf.org/internet-drafts/ Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin
draft-ietf-opes-iab-03.txt, October 2003. Stecher, Marshall Rose and Reinaldo Penno.
Author's Address 11. 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
EMail: abbieb@nortelnetworks.com EMail: abbieb@nortelnetworks.com
Appendix A. Acknowledgements 12. Full Copyright Statement
Several people has contributed to this work. Many thanks to: Alex Copyright (C) The Internet Society (2004).
Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin
Stecher, Marshall Rose and Reinaldo Penno.
Intellectual Property Statement This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the IETF's procedures with respect to rights in IETF Documents can
standards-related documentation can be found in BCP-11. Copies of be found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgement
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.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/