Network Working Group                                          A. Barbir
Internet-Draft                                           Nortel Networks
Expires: April 3, March 31, 2004                                   October 4,                                        Oct. 2003

               OPES processor entities and end points communications
                      draft-ietf-opes-end-comm-03 communication
                      draft-ietf-opes-end-comm-04

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 April 3, March 31, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This memo documents tracing and non-blocking requirements for Open
   Pluggable Edge Services (OPES).

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  OPES System  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Requirements for OPES Tracing  . . . . . . . . . . . . . . . .  5
   3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . .  5
   3.2 Requirements for Information Related to Traceable Entities OPES System . . . . . . . . . . . . . . . . .  6
   3.3 Requirements for OPES processors . . . . . . . . . . . . . . .  7
   3.4 Requirements for callout servers . . . . . . . . . . . . . . .  7
   3.5 Protocol Binding
   4.  Requirements for OPES System Bypass (Non-blocking feature) . .  8
   4.1 What can be bypassed in an OPES Flow?  . . . . . . . . . . . .  8
   4.2 Bypass requirements for OPES System  . . . . . . . . . .  8
   4.  Non-Blocking . . .  9
   4.3 Bypass requirements for OPES processors  . . . . . . . . . . .  9
   4.4 Bypass requirements for callout servers  . . . . . . . . . . .  9 10
   5.  Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 12
   6.
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.1 Tracing security considerations  . . . . . . . . . . . . . . . 13
   7.2 Bypass security considerations . . . . . . . . . . . . . . . . 14
       Normative References . . . . . . . . . . . . . . . . . . . . . 14 16
       Informative References . . . . . . . . . . . . . . . . . . . . 15 17
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 17
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 18
       Intellectual Property and Copyright Statements . . . . . . . . 17 19

1. Introduction

   The Open Pluggable Edge Services (OPES) architecture [8] [7] enables
   cooperative application services (OPES services) between a data
   provider, a data consumer, and zero or more OPES processors.  The
   application services under consideration analyze and possibly
   transform application-level messages exchanged between the data
   provider and the data consumer.

   This work specify specifies the requirements for providing tracing
   functionality for the OPES architecture [8]. [7]. Tracing functionality
   enables a data provider or a data consumer application to detect
   inappropriate actions that are performed by OPES entities. The work
   also develops requirements that can be used to fulfill IAB
   Notification and
   Non-Blocking Bypass (Non-Blocking) requirements [2].

   The architecture document requires [8] [7] that tracing be is supported
   in-band. This design goal limits the type of application protocols
   that OPES can support. The details of what a trace record can convey
   is
   are also dependent on the choice of the application level protocol.

   For these reasons, this work documents requirements for application
   protocols that need to support OPES traces and non-blocking. non-blocking
   mechanism. However, the architecture does not prevent implementers of
   developing out-of-band protocols and techniques to address these
   limitation.

2. OPES System

   This sections provides a definition of OPES System. This is needed in
   order to define what is traceable in an OPES Flow.

   Definition: An OPES System is a set of all OPES entities [7]
   authorized by either the data provider or the data consumer
   application to process a given application message.

   The nature of the authorization agreement determines if authority
   delegation is transitive (meaning an authorized entities entity is authorized
   to include other entities). Transitive authority
   delegation is common in information systems.

   If specific authority agreements allow for re-delegation, an OPES
   system can be formed by induction. In this case, an OPES system
   starts with entities directly authorized by a data provider (or a
   data consumer) application. The OPES system then includes any OPES
   entity authorized by an entity that is already in the OPES system.
   The authority delegation is always viewed in the context of a given
   application message.

   An OPES System is defined on an application message basis. Having an
   authority to process a message does not imply being involved in
   message processing. Thus, some OPES system members may not
   participate in processing of a message. Similarly, some members may
   process the same message several times.

   The above definition implies that there can be no more than one two OPES
   system
   systems [Client-side and server-side OPES systems can process the
   same message at the same time] processing a single the same message at a given
   time. This is based on the assumption that there is a single data
   provider and a single data consumer as far as a given application
   message is concerned.

   For example, consider a Content Delivery Network (CDN) delivering an
   image on behalf of a busy web site. OPES processors and services that
   the CDN uses to adapt and deliver the message comprise an OPES
   system.
   System. In a more complex example, an OPES System would contain CDN
   entries as well as 3rd-party OPES entities that CDN engages to
   perform adaptations (e.g., to adjust image quality).

3. Requirements for OPES Tracing

   In an OPES System tracing is defined as the inclusion of necessary
   information within a message in an OPES Flow that identify the set
   collection of transformations or adaptations that have been performed
   on it before its delivery to an end point (for example, the data
   consumer application). An OPES trace represents a snap shot of the
   tracing information that have been added to a given application
   message. A trace represents the collections of transformations on an
   application message in the order that were performed.  A traceable
   entity can appear multiple times in a trace (every time it acts on a
   message).

   In an OPES System tracing is performed on per message basis. Trace
   format is dependent on the application protocol that is being adapted
   by OPES. A Data data consumer application can use OPES trace to infer the
   actions that have been performed by the OPES system. System.  Actions are the
   set of authorized OPES services that were performed by OPES entities in an OPES
   System.

   Providing

   In an OPES System, the task of providing tracing information, MUST take into account the following
   considerations: can
   depend on many factors. Some considerations are:

   o  Providers may be hesitant to reveal information about their
      internal network infrastructure.

   o  Within a service provider network, OPES processors may be
      configured to use non-routable, private IP addresses.

   o  A Data data consumer applications would prefer to have a single point
      of contact regarding the trace information.

3.1 What is traceable in

   In an OPES Flow?

   This section focuses on identifying traceable entities in an System some OPES
   Flow.

   Tracing information provides a data consumer application (or a data
   provider application) with useful information without tracing the
   exact OPES Processor or callout servers that adapted the data. For
   example, some OPES services are message-agnostic and operate on
   message content or parts of services are message-agnostic and operate
   on message content or parts of a message. Such services cannot do not
   manipulate message headers. Other services can manipulate message
   headers. Hence, OPES providers require some freedom in the way they deliver
   tracing information to an end point.

3.1 What is traceable in an OPES Flow?

   This section focuses on identifying traceable entities in an OPES
   Flow.

   Tracing information provides a data consumer application would
   be interested in knowing that (or a translation service on the message
   content was performed. It does not need to know the exact entity data
   provider application) with information about OPES entities that
   has performed
   adapted the service. data. There are two distinct uses of OPES traces. First,
   a trace enables an "end (content provider or consumer) to detect the
   presence of OPES processors within an OPES System. Such "end" should
   be able to see a trace entry, but does not need to be able to
   interpret it beyond identification of the OPES System.

   Second, the OPES System administrator is expected to be able to
   interpret the contents of an OPES trace. The trace can be provided relayed to
   the administrator by an end (data consumer or provider) without
   interpretation, as an opaque string. data (e.g., a TCP packet or an HTTP message
   snapshot). The administrator can use the trace information to
   identify the participating OPES processor(s). entities. The administrator can use
   the trace to identify the applied adaptation services along with
   other message-specific information.

   Since the administrators of various OPES Systems can have various
   ways of looking into tracing, they MAY require the choice of freedom in
   what to put in trace records and how to format them. Trace records
   should be easy to extend beyond basic OPES requirements. Trace
   management algorithms should treat trace records as opaque data to
   the extent possible.

   At the implementation level, for a given trace, an OPES entity
   involved in handling the corresponding application message is
   traceable or traced if information about it appears in that trace.
   OPES entities have different levels of traceability requirements.
   Specifically,

   o  An OPES system MUST add its entry to the trace.

   o  An OPES processor SHOULD add its entry to the trace.

   o  An OPES service May add its entry to the trace.

   o  An OPES entity MAY manage trace information from entities that are
      under delegate addition of its control. trace entry to another
      OPES entity. For example, an OPES System can have a dedicated OPES
      processor may add or
      remove for adding System entries; an OPES processor can use a
      callout service entries in order to manage the size of a
      trace.

   From all OPES trace manipulations (since such
      manipulations are OPES adaptations).

   In an OPES context, a good tracing approach is similar to a trouble
   ticket ready for submission to a known address. The address is
   printed on the ticket. The trace in itself is not necessarily a
   detailed description of what has happened. It is the responsibility
   of the operator to resolve the problems.

3.2 Requirements for Information Related to Traceable Entities OPES System

   The following MUST requirements apply for information as related to
   entities that are traceable in an
   OPES flow: System:

   o  Identification of  An OPES system MUST add its identification to the trace.

   o  An  OPES System MUST include information about its privacy policy at the time it
      dealt with the message. policy.

   o  Identification of  An OPES System MUST identify the party responsible for setting and
      enforcing that policy.

   o  Information  An OPES System MUST include information pointing to a technical
      contact.

   o  Information  An OPES System MUST include information that identifies, to the
      technical contact, the OPES  processors involved in processing the
      message.

3.3 Requirements for OPES processors

   The

   In addressing the above requirements for OPES processors that are applicable and in order to tracing
   are:

   o  Each OPES processor MUST be uniquely identified in reduce the size
   of the trace, an OPES System. System can provide a URL to the OPES System web
   page that has links to privacy and other policies.

3.3 Requirements for OPES processors

   Tracing requirements for OPES processors are:

   o  Each OPES processor MUST support tracing, policy can be used to
      turn tracing on and to determine its granularity.

   o  If tracing is turned on, then the OPES processor MUST 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
      service(s) execution since it understands the application
      protocol. To fulfill this:

      *  An OPES processor MAY have a fixed configuration that enable it
         to respond to tracing inquires. For example, entity X performs
         service Y and so on.

      *  An OPES processor MAY package tracing information related to
         the entities that it control based on the policy of a given
         OPES System. For example, the trace may state that service W
         was performed. The OPES processor knows that service W is
         composed of services X, Y and Z in a given order

   o  An OPES processor SHOULD add to the trace identification of every
      callout service that processed the application message.

   o  An OPES processor MAY delegate trace management to  a callout
      service within the same OPES System.

3.4 Requirements for callout servers

   In an OPES system, it is the task of an OPES processor to add trace
   records to application messages. However, in some cases, callout
   servers May add trace information to application messages. This
   should be done under the control of the OPES System provider.

3.5 Protocol Binding

   The task of adding tracing information is application protocol
   specific. Separate documents will address HTTP and other protocols.
   This work documents what tracing information is required and some
   common tracing elements.

4. Non-Blocking

   In [9] recommendation addresses the issue of non-blocking in an Requirements for OPES
   System. The System Bypass (Non-blocking feature)

   IAB recommendation is restated below for ease of reference. (3.3) Non-blocking: If there exists a non-OPES version of content
      available from the content provider, [2] requires that the OPES architecture must does
   not prevent users a data consumer application from retrieving this non-OPES
   version of content from a data provider application, provided that
   the non-OPES content provider.

   The exists. IAB recommendation implies (3.3) suggests that it is up to
   the content provider Non-blocking feature (Bypass) be used to make non-OPES versions of a given content available. The actual
   meaning of non-OPES version of the content depended on the agreement
   between the OPES provider and the content provider. The agreement can
   allow bypass faulty OPES
   intermediaries (once they have been identified, by some method).

   In addressing IAB consideration (3.3), one need to perform specify what
   constitute non-OPES content. In some services (such as logging services) cases, the definition of
   "non-OPES" content is provider-dependent and
   prevent it from performing may include content
   adapted by OPES. Examples include content that is adapted for Black
   and White hand held devices or logging services. In other services (such as data to audio
   transformation).

   Whether an OPES System honor a non-blocking request from a data
   consumer application (user) cases, the
   availability of certain content can also be a function of deployment.
   Consider the case where internal
   policy of a given organization that has contracted the services of an
   OPES provider. For example, Company A has as contract with an OPES
   provider to perform virus checking on all e-mail attachments. An
   employee X of Company A can issue a non-blocking request for the
   virus scanning service. However, the request could be ignored by the
   OPES provider since it contradicts its agreement with Company A.  As
   a second example, a user may issue

   The above examples illustrates that the availability of non-OPES
   content can be a non-blocking request for adult
   content, function of content providers (or consumers or both)
   policy and deployment scenarios [1]. For this request may reason, this work does
   not attempt to define what is an OPES content as opposed to non-OPES
   content. The meaning of OPES versus non-OPES content is assumed to be declined by
   determined through various agreements between the OPES provider, data
   provider simply
   because it contradicts its internal policy or its agreement with the
   end subscriber.

   In some cases, a and data consumer application application. The agreement will issue a non-blocking
   request since it suspects that the OPES System is corrupting the
   data. For example, an also
   determine what OPES entity has determined that a Virus is
   present in an attachment, while the user is aware that some versions
   of virus scanners will make that mistake. In this case, the user services can
   use the non-blocking technique (can be used bypassed and in combination with the
   tracing facility) to solve the problem. However, whether the what order (if
   applicable).

   In an OPES System will honor the non-blocking a Bypass request or not is still a function defined as the act of avoiding
   the deployment scenario, content availability and related
   policies.

   Like tracing, Non-blocking operates on per application invocation of a service(s) that is identified by a URI within a
   message bases.
   Non-Blocking in an OPES Flow before its delivery to an end point (for
   example, the data consumer application).

4.1 What can be bypassed in an OPES Flow?

   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
   services. The collection of OPES services that can be bypassed is a
   function of the agreement of the OPES provider with either (or both)
   the content provider or the content consumer applications. In the
   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
   entities that perform a service (or services) to  be bypassed. An
   instruction may contain more than one such URI. A special wildcard
   identifier can be used to represent all possible URIs (i.e., all
   possible OPES services).

4.2 Bypass requirements for OPES System

   In an OPES System the Bypass feature is an end-end end-to-end operation as
   opposed to a hop-by-hop operation. Non-blocking Bypass requests are generally
   client centric and go in the opposite direction of tracing requests. Non-blocking
   Bypass can be performed out of band or in-band. This work requires non-blocking to
   that the Bypass feature be performed in-band as an extension to an
   application specific protocol. Non-OPES entities should be able to
   safely ignore the these extensions. The work does not prevent OPES
   Systems from developing their own out of band protocols.

   Non-blocking format is dependent on the application protocol

   The following requirements apply for Bypass feature as related to an
   OPES System:

   o  An OPES system MUST support a Bypass feature. This means that the
      OPES System bypasses an entity whose URI is
   being adapted identified by OPES. For an OPES
      end (usually data consumer application).

   o  An OPES System MUST treat a given application protocol, in Bypass request as an end-to-end
      operation. This applies to the whole system.

   o  An  OPES System there can be services that operate on 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
   experience) of the bypass feature in an OPES System, it would be
   beneficial if non-bypassed entities include information related to
   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
   OPES System (or part) may need to be bypassed through the issue of a
   bypass instruction.

4.3 Bypass requirements for OPES processors

   For a given application protocol, in an OPES System there can be
   services that operate on application message headers and those that
   just operate on content. This mix of service requires that an OPES
   processor that is calling the service(s) to handle the non-blocking bypass
   request. In some cases, the first OPES processor that will get the non-blocking
   bypass request may not be the first OPES processor that will know
   whether a non-OPES version of the content is available or not.

   In an OPES System, the

   Bypass requirements for OPES provider is expected to configure processors are:

   o  There MUST be at least one OPES processor in an OPES System that
      knows how to interpret and process a non-blocking header based on
   content availability and related policies. In this case the OPES
   processor is expected bypass request. This
      requirement applies to determine the set of services that will be
   bypassed (or all bypass instructions, including  those services
      that will be performed) or whether identify known-to-recipient entities.

   o  OPES processors that do not know how to process a bypass request
      MUST forward the request should be forwarded directly to the data provider next application
   (origin content provider).

   Although, IAB recommendation (3.3) has intended for non-blocking
   approach to be used as a vehicle to bypass faulty OPES
   intermediaries. However, this work recognizes hop provided that
      the same technique
   can be used to enable a data consumer next hop speaks application to select the set protocol with OPES bypass support.

   o  The recipient of services that it would like to be bypassed for a given application
   message. For this reason, a non-blocking request is viewed as a bypass instruction that contains with a URI that identifies an does not
      identify any known-to-recipient OPES entity
   or a group of OPES entities MUST treat that perform URI as
      a service (or services) to
   be bypassed. An instruction may contain more than one such URI. A
   special wildcard identifier can be used to represent all possible
   URIs (i.e., (meaning bypass all possible OPES applicable services). This version of the work
   requires that all non-blocking instructions to use the wildcard
   approach.

   For example, an application level protocol (such as HTTP) can

   o  OPES processor SHOULD be
   extended able to include bypass it's own invocation and
      service(s) execution since it understands the following OPES non-blocking related header:

      OPES-Bypass: *

   The following application
      protocol.

4.4 Bypass requirements apply for non-blocking feature:

   o  An callout servers

   In an OPES System MUST support system, it is the non-blocking feature for requests task of non-OPES content for a given application message.

   o  An OPES System MUST treat the non-blocking feature as an
      end-to-end operation.

      *  This means that there MUST be at least one OPES processor in an
         OPES System that knows how to interpret and process
   bypass requests.  However, in some cases, callout servers May be
   involved in processing Bypass requests. This should be done under the
         non-blocking feature.

      *
   control of the OPES System provider.

5. Protocol Binding

   The recipient MUST forward task of encoding tracing and bypass features is application
   protocol specific. Separate documents will address HTTP and other
   protocols.

6. IANA considerations

   This specification contains no IANA considerations. Application
   bindings MAY contain application-specific IANA considerations.

7. Security Considerations

   The security considerations for OPES are documented in [6]. This
   document is a requirement document for tracing and Bypass feature.
   The requirements that are stated in this document can be used to
   extend an application level protocol to support these features. As
   such, the work has security precautions.

7.1 Tracing security considerations

   The tracing facility for OPES architecture is implemented as a
   protocol extension. Inadequate implementations of the tracing
   facility may defeat safeguards built into the OPES architecture. The
   tracing facility by itself can become a target of malicious attacks
   or used to lunch attacks on an OPES System.

   Threats caused by or against the tracing facility can be viewed as
   threats at the application level in an OPES Flow. In this case, the
   threats can affect the data consumer and the data provider
   application.

   Since tracing information is a protocol extension, these traces can
   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
   fashion that threat the overall integrity and effectiveness of an
   OPES System. For example, a non-OPES proxy can add fake tracing
   information into a trace. This can be done in the form of wrong, or
   unwanted, or non existent services. A non-OPES entity can inject
   large size traces that may cause buffer overflow in a data consumer
   application. The same threats can arise from compromised OPES
   entities. An attacker can control an OPES entity and inject wrong, or
   very large trace information that can overwhelm an end or the next
   OPES entity in an OPES flow. Similar threats can result from bad
   implementations of the tracing facility in trusted OPES entities.

   Compromised tracing information can be used to launch attacks on an
   OPES System that give the impression that unwanted content
   transformation was performed on the data. This can be achieved by
   inserting wrong entity (such OPES processor) identifiers. A
   compromised trace can affect the overall message integrity structure.
   This can affect entities that use message header information to
   perform services such as accounting, load balancing, or
   reference-based services.

   Compromised trace information can be used to launch DoS attacks that
   can overwhelm a data consumer application or an OPES entity in an
   OPES Flow. Inserting wrong tracing information can complicates the
   debugging tasks performed by system administrator during trouble
   shooting of OPES System behavior.

   Specific protocol binding documents ought to take these security
   threats into consideration. It is recommended that protocol bindings
   provide safe features into their specifications. Such features may
   include a place holder in the message header that indicates the size
   of the trace. Other holders can include the option of signing the
   trace information as a proof of authenticity.

   As a precaution, OPES entities ought to be capable of verifying that
   the inserted traces are performed by legal OPES entities. This can be
   done as part of the authorization and authentication face. Policy can
   be used to indicate what trace information can be expected from a
   peer entity. Other application level related security concerns can be
   found in [6].

7.2 Bypass security considerations

   The bypass facility for OPES architecture is implemented as a
   protocol extension. Inadequate implementations of the bypass facility
   may defeat safeguards built into the OPES architecture. The bypass
   facility by itself can become a target of malicious attacks or used
   to lunch attacks on an OPES System.

   Threats caused by or against the bypass facility can be viewed as
   threats at the application level in an OPES Flow. In this case, the
   threats can affect the data consumer and the data provider
   application.

   There are risks for the OPES System by non-OPES entities, whereby,
   these entities can insert bypass instructions into the OPES Flow. The
   threat can come from compromised non-OPES entities. The threat might
   affect the overall integrity and effectiveness of an OPES System. For
   example, a non-OPES proxy can add bypass instruction to bypass
   legitimate OPES entities. The attack might result in overwhelming the
   original content provider servers, since the attack essentially
   bypass any load balancing techniques. In addition, such an attack is
   also equivalent to a DoS attack, whereby, a legitimate data consumer
   application may not be able to access some content from a content
   provider or its OPES version.

   Since an OPES Flow may include non-OPES entities, it is susceptible
   to man-in-the-middle attacks, whereby an intruder may inject bypass
   instructions into the data path. These attacks may affect content
   availability or disturb load balancing techniques in the network.

   The above threats can also arise by compromised OPES entities. An
   intruder can compromise an OPES entities and then use
   man-in-the-middle techniques to disturb content availability to a
   data consumer application or overload a content provider server
   (essentially, some form of a DoS attack).

   Attackers can use the bypass instructions instruction to affect the next
         application hop provided that overall
   integrity of the next hop speaks application
         protocol with OPES bypass support.

      *  This requirement applies System. The ability to all illegally introduce
   bypass instructions, including
         those that identify known-to-recipient entities.

   o  Application-specific bindings MUST map the above non-blocking
      mechanism to their application protocol.

   End users instructions into a data flow may not be able to know if their non-blocking request was
   honored or not by effect the accounting of the
   OPES System. In this case, it would be
   beneficial if tracing can provide additional information regarding
   whether a non-blocking request was honored or not. For this reason,
   the following requirement It may also apply to affect the tracing facility:

   o  An OPES System SHOULD assist quality of content that is
   delivered to the data consumer application in
      determining if a non-blocking request was performed by applications. Similar threats can
   arise from bad implementations of the system.

   Assistance bypass facility.

   Specific protocol binding documents ought to take these security
   threats into consideration. It is viewed as the addition of information about services recommended that were skipped and those protocol bindings
   provide safe features into their specifications. Such features may
   include a place holder in the message header that could not be bypassed.

5. IANA considerations

   This work does not require any IANA consideration since any actions
   will indicates who
   originated the bypass request. Other holders can include the option
   of signing the bypass request as a proof of identity. Other
   application level related security concerns can be addressed found in [6].

6. Security Considerations

   The security considerations for OPES are documented in [7]. This
   document is a requirement document for tracing and non-blocking and
   as such does not develop any new protocols that require security
   considerations.

Normative References

   [1]  A. Barbir et al., "OPES Use Cases and Deployment Scenarios",
        Internet-Draft http://www.ietf.org/internet-drafts/
        draft-ietf-opes-scenarios-01.txt, August 2002.

Informative References

   [2]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

   [3]  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.

   [4]  A. Barbir et al., "Policy, Authorization and Enforcement
        Requirements of OPES", Internet-Draft http://www.ietf.org/
        internet-drafts/draft-ietf-opes-authorization-02.txt, February
        2003.

   [5]  Rousskov, A., "OPES Callout Protocol Core", Internet-Draft
        http://www.ietf.org/internet-drafts/
        draft-ietf-opes-ocp-core-01.txt, August  2003.

   [6]  Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD,
        September 2003.

   [7]

   [6]  A. Barbir et al., "Security Threats and Risks for Open Pluggable
        Edge Services", Internet-Draft http://www.ietf.org/
        internet-drafts/draft-ietf-opes-threats-02.txt, February 2003.

   [8]

   [7]  A. Barbir et al., "An Architecture for Open Pluggable Edge
        Services (OPES)", Internet-Draft http://www.ietf.org/
        internet-drafts/draft-ietf-opes-architecture-04, December  2002.

   [9]

   [8]  A. Barbir et al., "OPES Treatment of IAB Considerations",
        Internet-Draft http://www.ietf.org/internet-drafts/
        draft-ietf-opes-iab-01.txt,
        draft-ietf-opes-iab-02.txt, February  2004.

Informative References

   [10]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
         Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
         Waldbusser, "Terminology for Policy-Based Management", RFC
         3198, November 2001.

   [11]  L. Cranor,  et. al, "The Platform for Privacy Preferences 1.0
         (P3P1.0) Specification", W3C Recommendation 16 http://
         www.w3.org/TR/2002/REC-P3P-20020416/ , April  2002.

Author's Address

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763 5229
   EMail: abbieb@nortelnetworks.com

Appendix A. Acknowledgements

   Several people has contributed to this work. Many thanks to: Alex
   Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin
   Stecher, Marshall Rose and Reinaldo Penno.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2003). 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

   Funding for the RFC Editor function is currently provided by the
   Internet Society.