draft-ietf-opes-end-comm-04.txt   draft-ietf-opes-end-comm-05.txt 
Network Working Group A. Barbir Network Working Group A. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: March 31, 2004 Oct. 2003 Expires: March 31, 2004 Oct. 2003
OPES entities and end points communication OPES entities and end points communication
draft-ietf-opes-end-comm-04 draft-ietf-opes-end-comm-05
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 38 skipping to change at page 1, line 38
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 March 31, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This memo documents tracing and non-blocking requirements for Open This memo documents tracing and non-blocking (bypass) requirements
Pluggable Edge Services (OPES). for Open Pluggable Edge Services (OPES).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements for OPES Tracing . . . . . . . . . . . . . . . . 5 3. Requirements for OPES Tracing . . . . . . . . . . . . . . . . 5
3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . . 5 3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . . 5
3.2 Requirements for OPES System . . . . . . . . . . . . . . . . . 6 3.2 Requirements for OPES System . . . . . . . . . . . . . . . . . 6
3.3 Requirements for OPES processors . . . . . . . . . . . . . . . 7 3.3 Requirements for OPES processors . . . . . . . . . . . . . . . 7
3.4 Requirements for callout servers . . . . . . . . . . . . . . . 7 3.4 Requirements for callout servers . . . . . . . . . . . . . . . 7
4. Requirements for OPES System Bypass (Non-blocking feature) . . 8 4. Requirements for OPES System Bypass (Non-blocking feature) . . 8
4.1 What can be bypassed in an OPES Flow? . . . . . . . . . . . . 8 4.1 What can be bypassed in an OPES Flow? . . . . . . . . . . . . 8
4.2 Bypass requirements for OPES System . . . . . . . . . . . . . 9 4.2 Bypass requirements for OPES System . . . . . . . . . . . . . 9
4.3 Bypass requirements for OPES processors . . . . . . . . . . . 9 4.3 Bypass requirements for OPES processors . . . . . . . . . . . 10
4.4 Bypass requirements for callout servers . . . . . . . . . . . 10 4.4 Bypass requirements for callout servers . . . . . . . . . . . 10
5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Compliance Considerations . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1 Tracing security considerations . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.2 Bypass security considerations . . . . . . . . . . . . . . . . 14 8.1 Tracing security considerations . . . . . . . . . . . . . . . 14
Normative References . . . . . . . . . . . . . . . . . . . . . 16 8.2 Bypass security considerations . . . . . . . . . . . . . . . . 15
Informative References . . . . . . . . . . . . . . . . . . . . 17 Normative References . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 Informative References . . . . . . . . . . . . . . . . . . . . 18
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 20
1. Introduction 1. Introduction
The Open Pluggable Edge Services (OPES) architecture [7] enables The Open Pluggable Edge Services (OPES) architecture [8] 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 the requirements for providing tracing
functionality for the OPES architecture [7]. Tracing functionality functionality for the OPES architecture [8]. Tracing functionality
enables a data provider or a data consumer application to detect enables a data provider or a data consumer application to detect
inappropriate actions that are performed by OPES entities. The work inappropriate actions that are performed by OPES entities. The work
also develops requirements that can be used to fulfill IAB also develops requirements that can be used to fulfill IAB
Notification and Bypass (Non-Blocking) requirements [2]. Notification and Bypass (Non-Blocking) requirements [2].
The architecture document requires [7] that tracing is supported The architecture document requires [8] that tracing is supported
in-band. This design goal limits the type of application protocols in-band. This design goal limits the type of application protocols
that OPES can support. The details of what a trace record can convey that OPES can support. The details of what a trace record can convey
are also dependent on the choice of the application level protocol. are also dependent on the choice of the application level protocol.
For these reasons, this work documents requirements for application For these reasons, this work documents requirements for application
protocols that need to support OPES traces and non-blocking protocols that need to support OPES traces and non-blocking
mechanism. However, the architecture does not prevent implementers of mechanism. The architecture does not prevent implementers of
developing out-of-band protocols and techniques to address these developing out-of-band protocols and techniques to address these
limitation. limitation. In this document the key words that are used to signify
requirements are based on RFC 2119 [3].
2. OPES System 2. OPES System
This sections provides a definition of OPES System. This is needed in This sections provides a definition of OPES System. This is needed in
order to define what is traceable in an OPES Flow. order to define what is traceable in an OPES Flow.
Definition: An OPES System is a set of all OPES entities [7] Definition: An OPES System is a set of all OPES entities [8]
authorized by either the data provider or the data consumer authorized by either the data provider or the data consumer
application to process a given application message. application to process a given application message.
The nature of the authorization agreement determines if authority The nature of the authorization agreement determines if authority
delegation is transitive (meaning an authorized 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
skipping to change at page 6, line 29 skipping to change at page 6, line 29
should be easy to extend beyond basic OPES requirements. Trace should be easy to extend beyond basic OPES requirements. Trace
management algorithms should treat trace records as opaque data to management algorithms should treat trace records as opaque data to
the extent possible. the extent possible.
At the implementation level, for a given trace, an OPES entity At the implementation level, for a given trace, an OPES entity
involved in handling the corresponding application message is involved in handling the corresponding application message is
traceable or traced if information about it appears in that trace. traceable or traced if information about it appears in that trace.
OPES entities have different levels of traceability requirements. OPES entities have different levels of traceability requirements.
Specifically, Specifically,
o An OPES processor SHOULD add its entry to the trace. o An OPES processor MUST 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 resolve the problems.
3.2 Requirements for OPES System 3.2 Requirements for OPES System
The following requirements apply for information as related to an The following requirements apply for information as related to an
OPES System: OPES System:
o An OPES system MUST add its identification to the trace. o An OPES System MUST trace itself.
o An OPES System MUST include information about its privacy policy. o An OPES System MUST include information about its privacy policy.
o An OPES System MUST identify the party responsible for setting and o An OPES System MUST identify the party responsible for setting and
enforcing that policy. enforcing that policy.
o An OPES System MUST include information pointing to a technical o An OPES System MUST include information pointing to a technical
contact. contact.
o An OPES System MUST include information that identifies, to the o An OPES System MUST 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.
In addressing the above requirements and in order to reduce the size o When providing required information, an OPES System MAY use a
of the trace, an OPES System can provide a URL to the OPES System web single URI to identify a resource containing several required
page that has links to privacy and other policies. items. For example, an OPES System can point to a single web page
with a reference to System privacy policy and technical contact
information.
This specification does not define the meaning of the terms privacy
policy, policy enforcement, or technical contact and contains no
requirements regarding encoding, language, format, or any other
aspects of that information. Furthermore, an example of System
identification would be something like http://www.examplecompany.com/
opes/?client=example.com.
3.3 Requirements for OPES processors 3.3 Requirements for OPES processors
Tracing requirements for OPES processors are: Tracing requirements for OPES processors are:
o Each OPES processor MUST support tracing, policy can be used to o OPES processor MUST add its unique identification to the trace.
turn tracing on and to determine its granularity. Here, uniqueness scope is the OPES System containing the
processor.
o If tracing is turned on, OPES processor SHOULD add its unique
identification to the trace. Here, uniqueness scope is the OPES
System containing the processor.
o OPES processor SHOULD be able to trace it's own invocation and o OPES processor MUST be able to trace it's own invocation and
service(s) execution since it understands the application service(s) execution.
protocol.
3.4 Requirements for callout servers 3.4 Requirements for callout servers
In an OPES system, it is the task of an OPES processor to add trace In an OPES system, it is the task of an OPES processor to add trace
records to application messages. However, in some cases, callout records to application messages. However, in some cases, callout
servers May add trace information to application messages. This servers may add trace information to application messages. This
should be done under the control of the OPES System provider. should be done under the control of the OPES System provider.
4. Requirements for OPES System Bypass (Non-blocking feature) 4. Requirements for OPES System Bypass (Non-blocking feature)
IAB recommendation (3.3) [2] requires that the OPES architecture does IAB recommendation (3.3) [2] 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 some cases, the definition of constitute non-OPES content. In this work the definition of
"non-OPES" content is provider-dependent and may include content "non-OPES" content is provider dependent. However, in some cases, the
adapted by OPES. Examples include content that is adapted for Black availability of "non-OPES" content can also be a function of the
and White hand held devices or logging services. In other cases, the internal policy of a given organization that has contracted the
availability of certain content can be a function of the internal services of an OPES provider. For example, Company A has as contract
policy of a given organization that has contracted the services of an with an OPES provider to perform virus checking on all e-mail
OPES provider. For example, Company A has as contract with an OPES attachments. An employee X of Company A can issue a non-blocking
provider to perform virus checking on all e-mail attachments. An request for the virus scanning service. However, the request could be
employee X of Company A can issue a non-blocking request for the ignored by the OPES provider since it contradicts its agreement with
virus scanning service. However, the request could be ignored by the Company A.
OPES provider since it contradicts its agreement with Company A.
The above examples illustrates that the availability of non-OPES The above examples illustrates that the availability of non-OPES
content can be a function of content providers (or consumers or both) content can be a function of content providers (or consumers or both)
policy and deployment scenarios [1]. For this reason, this work does policy and deployment scenarios [1]. For this reason, this work does
not attempt to define what is an OPES content as opposed to non-OPES not attempt to define what is an OPES content as opposed to non-OPES
content. The meaning of OPES versus non-OPES content is assumed to be content. The meaning of OPES versus non-OPES content is assumed to be
determined through various agreements between the OPES provider, data determined through various agreements between the OPES provider, data
provider and data consumer application. The agreement will also provider and data consumer application. The agreement will also
determine what OPES services can be bypassed and in what order (if determine what OPES services can be bypassed and in what order (if
applicable). applicable).
In an OPES System a Bypass request is defined as the act of avoiding In an OPES System a bypass request is defined as the act of avoiding
the invocation of a service(s) that is identified by a URI within a the invocation of a service(s) that is identified by a URI within a
message in an OPES Flow before its delivery to an end point (for message in an OPES Flow before its delivery to an end point (for
example, the data consumer application). example, the data consumer application). The availability of non-OPES
content is a precondition to whether a bypass instruction is honored
or not in an OPES System.
4.1 What can be bypassed in an OPES Flow? 4.1 What can be bypassed in an OPES Flow?
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 (i.e., all
possible OPES services). possible OPES services that are relevant to an OPES processor).
In an OPES Flow, a bypass request is processed in a local manner by
each involved OPES processor. This means that an OPES processor
examines the bypass instruction and if non-OPES content is available,
the processor then bypasses services that are local to itself. This
may include the act of bypassing itself completely depending on what
is specified in the URI. The request is then forwarded to the next
OPES processor in the OPES Flow. The next OPES processor would then
honor all bypass requests that are relevant to it provided that the
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 Bypass requirements for OPES System
In an OPES System the Bypass feature is an end-to-end operation as In an OPES System bypass requests are generally client centric and go
opposed to a hop-by-hop operation. Bypass requests are generally in the opposite direction of tracing requests. Bypass can be
client centric and go in the opposite direction of tracing requests. performed out of band or in-band. This work requires that the Bypass
Bypass can be performed out of band or in-band. This work requires feature be performed in-band as an extension to an application
that the Bypass feature be performed in-band as an extension to an specific protocol. Non-OPES entities should be able to safely ignore
application specific protocol. Non-OPES entities should be able to these extensions. The work does not prevent OPES Systems from
safely ignore these extensions. The work does not prevent OPES developing their own out of band protocols.
Systems from 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: OPES System (the availability of a non-OPES content is a
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 an entity whose URI is identified by an OPES
end (usually data consumer application). end (usually data consumer application).
o An OPES System MUST treat a Bypass request as an end-to-end
operation. This applies to the whole system.
o An OPES System MUST include information about its bypass policy.
o An OPES System MUST identify the party responsible for setting and
enforcing the bypass policy.
o An OPES System MUST include information that identifies, to a
technical contact, the OPES processors involved in processing the
bypass request.
In addressing the above requirements an OPES System can provide a URL
to the OPES System web page that has links to Bypass and other
policies.
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 Bypass requirements for OPES processors
For a given application protocol, in an OPES System there can be For a given application protocol, in an OPES System there can be
services that operate on application message headers and those that services that operate on application message headers and those that
just operate on content. This mix of service requires that an OPES just operate on content. This mix of service requires that an OPES
processor that is calling the service(s) to handle the bypass processor that is calling the service(s) to handle the bypass
request. In some cases, the first OPES processor that will get the request. In some cases, the first OPES processor that will get the
bypass request may not be the first OPES processor that will know bypass request may not be the first OPES processor that will know
whether a non-OPES version of the content is available or not. whether a non-OPES version of the content is available or not.
Bypass requirements for OPES processors are: Bypass requirements for OPES processors are (the availability of a
non-OPES content is a precondition):
o There MUST be at least one OPES processor in an OPES System that o OPES processor SHOULD be able to interpret and process a bypass
knows how to interpret and process a bypass request. This instruction. This requirement applies to all bypass instructions,
requirement applies to all bypass instructions, including those including those that identify known-to-recipient services.
that identify known-to-recipient entities.
o OPES processors that do not know how to process a bypass request o OPES processors that do not know how to process a bypass request
MUST forward the request to the next application hop provided that MUST forward the request to the next application hop provided that
the next hop speaks application protocol with OPES bypass support. the next hop speaks application protocol with OPES bypass support.
o OPES processor SHOULD be able to bypass it's service(s) execution.
Provided that non-OPES content is available, those OPES processors
that know how to process and interpret a bypass 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 local
services).
o OPES processor SHOULD be able to bypass it's own invocation and
service(s) execution since it understands the application
protocol.
4.4 Bypass requirements for callout servers 4.4 Bypass requirements for callout servers
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. However, in some cases, callout servers may be
involved in processing Bypass requests. This should be done under the involved in processing Bypass requests. This should be done under the
control of the OPES System provider. 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.
6. IANA considerations 6. Compliance Considerations
This work specifies high level requirements for tracing and bypass.
Protocol binding specifications MUST consider and follow all MUSTs in
this draft. Protocol binding specifications MUST be compliant to this
draft. As such any implementation compliant to the binding
specification is also compliant to this draft.
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.
7. Security Considerations 8. Security Considerations
The security considerations for OPES are documented in [6]. This The security considerations for OPES are documented in [7]. 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.
7.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 6 skipping to change at page 15, line 6
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-based services. reference-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 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.
Specific protocol binding documents ought to take these security
threats into consideration. It is recommended that protocol bindings
provide safe features into their specifications. Such features may
include a place holder in the message header that indicates the size
of the trace. Other holders can include the option of signing the
trace information as a proof of authenticity.
As a precaution, OPES entities ought to be capable of verifying that 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 [6]. found in [7].
7.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
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 15, line 9 skipping to change at page 15, line 50
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-middle techniques to disturb content availability to a man-in-the-middle techniques to disturb content availability to a
data consumer application or overload a content provider server data consumer application or overload a content provider server
(essentially, some form of a DoS attack). (essentially, some 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 illegally introduce integrity of the OPES System. The ability to introduce bypass
bypass instructions into a data flow may effect the accounting of the instructions into a data flow may effect the accounting of the OPES
OPES System. It may also affect the quality of content that is System. It may also affect the quality of content that is delivered
delivered to the data consumer applications. Similar threats can to the data consumer applications. Similar threats can arise from bad
arise from bad implementations of the bypass facility. implementations of the bypass facility.
Specific protocol binding documents ought to take these security Inconsistent or selective bypass is also a threat. Here, one end can
threats into consideration. It is recommended that protocol bindings try to bypass a subset of OPES entities so that the resulting content
provide safe features into their specifications. Such features may is malformed and crashes or compromises entities that process that
include a place holder in the message header that indicates who content (and expect that content to be complete and valid). Such
originated the bypass request. Other holders can include the option exceptions are often not tested because implementers do not expect a
of signing the bypass request as a proof of identity. Other vital service to disappear from the processing loop.
application level related security concerns can be found in [6].
Other threats can arise from configuring access control policies for
OPES entities. It is possible that systems implementing access
controls via OPES entities may be incorrectly configured to honor
bypass and, hence, give unauthorized access to intruders.
Tap bypass can also be a threat. This is because systems implementing
wiretaps via OPES entities may be incorrectly configured to honor
bypass and, hence, ignore (leave undetected) traffic with bypass
instructions that should have been tapped or logged. It is also
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
throughout the network.
Other application level related security concerns can be found in
[7].
Normative References Normative References
[1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", [1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios",
Internet-Draft http://www.ietf.org/internet-drafts/ Internet-Draft http://www.ietf.org/internet-drafts/
draft-ietf-opes-scenarios-01.txt, August 2002. draft-ietf-opes-scenarios-01.txt, August 2002.
Informative References Informative References
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238, Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002. January 2002.
[3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
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.
[4] A. Barbir et al., "Policy, Authorization and Enforcement [5] A. Barbir et al., "Policy, Authorization and Enforcement
Requirements of OPES", Internet-Draft http://www.ietf.org/ Requirements of OPES", Internet-Draft http://www.ietf.org/
internet-drafts/draft-ietf-opes-authorization-02.txt, February internet-drafts/draft-ietf-opes-authorization-02.txt, February
2003. 2003.
[5] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD, [6] Rousskov, A. et al, "HTTP adaptation with OPES", Internet-Draft
September 2003. http://www.ietf.org/internet-drafts/draft-ietf-opes-http-00.txt,
July 2003.
[6] A. Barbir et al., "Security Threats and Risks for Open Pluggable [7] 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.
[7] A. Barbir et al., "An Architecture for Open Pluggable Edge [8] A. Barbir et al., "An Architecture for Open Pluggable Edge
Services (OPES)", Internet-Draft http://www.ietf.org/ Services (OPES)", Internet-Draft http://www.ietf.org/
internet-drafts/draft-ietf-opes-architecture-04, December 2002. internet-drafts/draft-ietf-opes-architecture-04, December 2002.
[8] 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, February 2004. draft-ietf-opes-iab-02.txt, September 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/