2.1.8 Open Pluggable Edge Services (opes)

Last Modified: 2003-07-24

Marshall T. Rose <mrose+mtr.ietf@dbc.mtview.ca.us>
Markus Hofmann <hofmann@bell-labs.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
Applications Area Advisor:
Ned Freed <ned.freed@mrochek.com>
Technical Advisor(s):
Allison Mankin <mankin@psg.com>
Hilarie Orman <ho@alum.mit.edu>
Mailing Lists:
General Discussion: ietf-openproxy@imc.org
To Subscribe: ietf-openproxy-request@imc.org
Archive: http://www.imc.org/ietf-openproxy/mail-archive/
Description of Working Group:
The Internet facilitates the development of networked services at the
application level that both offload origin servers and mediate the
user experience. Proxies are commonly deployed to provide such
services as web caching, request filtering and virus scanning. Lack
of standardized mechanisms to trace and to control such intermediaries
causes problems with respect to failure detection, data integrity,
privacy, and security.

The Open Pluggable Edge Services (OPES) working group is chartered
to define a framework and protocols to both authorize and invoke
distributed application services while maintaining the network's
robustness and end-to-end data integrity. These services may be
server-centric (i.e., an administrative domain that includes the
origin server) and they may be client-centric (i.e., an
administrative domain that includes the user agent).

Services provided in the OPES framework should be traceable by the
application endpoints of an OPES-involved transaction, thus helping
both service providers and end-users detect and respond to
inappropriate behavior by OPES components. In particular, services
provided in the OPES framework should be reversible by mutual
agreement of the application endpoints. Furthermore, the OPES
protocol must include authorization as one if its steps,
and this must be by at least one of the of the application-layer
endpoints (i.e. either the content provider or the content consumer).

In a first step, this working group will investigate and
propose to the Area Directors whether the architecture to be
developed must be compatible with the use of end-to-end integrity
and encryption. Based on this decision, it will examine the
requirements for both authorization and invocation of application
services inside the network. The group will create an architecture for
OPES services applied to application messages, and specify the protocol
for HTTP and RTP/RTSP. The working group will define one or more
methods for specification of policies, as well as the rules that enable
application endpoints to control execution of such services.

The working group will have a design goal that policies affecting
the control and authorization rules be compatible with existing
policy work within the IETF (e.g. IETF Policy Framework) and be
able to interface with systems automating distribution of policies to
multiple endpoints, but it will be out of scope for this work to
develop the policy framework and specify multiple-endpoint policy

With the requirements, the working group will specify a protocol or
suite of protocols for invocation and tracking of OPES services inside
the net, including the authorization and enforcement elements for one

The working group will consider the ICAP protocol drafts as an OPES
precursor and will will support development of an analysis that
explains the limitations of ICAP, to accompany informational
publication of that protocol. The working group will coordinate with
other groups such as AVT and MMUSIC (in regard to RTP/RTSP) and WEBI
(in regard to HTTP).

The group's work items can be listed as:

- Develop scenarios and use case document.

- Draft high-level, overall example OPES architecture.

- Define requirements for service invocation and tracing (callout).

- Define policy specification method(s) and rules for controlling
  execution of OPES services.

- Define callout and tracing protocol(s).

- Develop a vulnerability assessment and use this to guide each type
  of security service to be included in the protocols developed.

As each deliverable is developed, it must address the IAB
considerations specified in RFC 3238.


- OPES scenarios and use case document.

- General OPES architecture/framework.

- Requirements for authorization and enforcement of OPES services.

- Requirements for invocation and tracking of OPES services.

- Vulnerability assessment document for OPES services.

- Mechanisms and protocols for service invocation and service tracking.
Goals and Milestones:
Done  Submit OPES scenarios document and architecture document to IESG for Informational.
Done  Submit document on protocol (callout and tracing) requirements to IESG for Informational.
Done  Submit document on endpoint authorization and enforcement requirements to IESG for Informational.
Done  Submit document on threat/risk model for OPES services to IESG for Informational.
Done  Initial protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization.
Aug 03  Initial document on rules specification method.
Sep 03  Submit protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization to IESG for Proposed Standard.
Oct 03  Submit document on rules specification method to IESG for Proposed Standard.
Oct 03  Consider additional OPES work such as extension to traffic beyond HTTP and RTSP and present new charter to IESG, or conclude working group.
  • - draft-ietf-opes-architecture-04.txt
  • - draft-ietf-opes-protocol-reqs-03.txt
  • - draft-ietf-opes-scenarios-01.txt
  • - draft-ietf-opes-authorization-02.txt
  • - draft-ietf-opes-threats-02.txt
  • - draft-ietf-opes-ocp-core-00.txt
  • - draft-ietf-opes-end-comm-00.txt
  • - draft-ietf-opes-iab-00.txt
  • - draft-ietf-opes-http-00.txt
  • No Request For Comments

    Current Meeting Report

    agreed.Minutes of the 57th Vienna OPES WG.
    Tuesday, July 15 at 0900-11:30
    CHAIRS: Markus Hofmann <hofmann@bell-labs.com>
    Minutes by Dimitri Tombroff.
    1 Introduction and General Status:
    Status of OPES documents: Initial versions of 
    (draft-ietf-opes-end-comm-00.txt) and OPES core protocol 
    (draft-ietf-opes-ocp-core-00.txt) have been published. An individual 
    submission about OCP/HTTP mapping has also been published, and the group 
    intendes to adopt this draft as WG document.
    General comments from the chair:
    - WG needs more participants for reviewing drafts and brings in 
    - WG needs additional focusing on tracing/bypassing issues.
    - WG is late with the rule language. Need expert contributors to start 
    2 Work on "Tracing/Bypass" document [P. Knight]
    Main issues is to decide on is traceable in an OPES flow, how to do it, and 
    what are the requirements and privacy issues.
    The WG approach is to use in-band tracing on a per message flow with the 
    following requirements:
    - an OPES system MUST be traceable
    - an OPES processor SHOULD be traceable
    - an OPES service  MAY be traceable.
    question: this works only for application protocols that allow for 
    in-band signaling of meta information. How would the first MUST apply to 
    other application protocols?
    answer: At this point, it is assumed that the appplication protocol will 
    have to support in-band signaling, which is in-line with the WG's 
    charter to focus on HTTP. This issue should be mentioned in the drafts.
    question : what motivates the MUST, SHOULD, and MAY at three different 
    levels ?
    answer: if you have a chain of processor, it may be unecessary that each 
    processor adds a trace. One per domain is enough.
    On 'How to support tracing', the chair noted that although the WG has so far 
    ruled out out-of-band notifications, more  input is needed to confirm it is 
    the correct approach. It was suggested that the resulting discussion 
    should be reflected in the document(s).
    On another issue, the WG needs to detail the definition of an "OPES 
    3 OPES Core Callout Protocol presented [Martin Stecher]
    The core OCP  was presented. This was a rather detailed 
    presentation, the remarks and questions were the following:
    The chair pointed out that there are still many open issues and 
    optional mechanisms to discuss - just see the TBD section and the 
    sections marked with XXX in the drafts. If no one is supporting the 
    inclusion of currently open/optional mechanisms (e.g. capability query) on 
    the mailing list, they will be removed for the sake of protocol 
    Performance is of big concern, and the WG needs to show benefits of OCP 
    over ICAP.
    It was noted that after long discussions about using BEEP, SOAP, or HTTP, 
    the consensus has been to move forward with a custom tailored 
    transport protocol for OCP, and see how it works. Progresses have been 
    mostly made on  OCP messages format.
    The 'can you' and 'do you' set of messages might bring unecessary 
    complication. Some input is needed to check if they are worthwhile.
    question : Since OCP is defined by a BNF grammar, is or will a parser be 
    provided ?
    answer: none so far.
    4 OCP Http Adaptation [Martin Stecher]
    The http adaptation was presented, as well as the status of prototype 
    callout servers by A. Rousskov and M. Stecher.
    One issue was raised about HTTP keep-alive connections and HTTP/1.1 
    pipelining. The problem is that the callout server may have to 
    transform a keep-alive http reply into a closed reply, because it may not be 
    able to set the correct Content-Length http header, nor use the chunked 
    transfer encoding.
    Having a callout generating closed http replies is bad because it breaks two 
    desirable http properties: keep-alive connections and thus http 
    pipelining (if any). It was also pointed out that it is not clear if it's 
    the callout server responsability or the OPES processor 
    responsability to handle such closing.
    5 OPES treatment of IAB Consideration [P. Knight]
    IAB considerations were discussed. The goal is to show that all IAB 
    considerations are addressed. Only IAB considerations are mentioned in this 
    document that triggered some remarks/questions during the meeting.
    5.0 IP layer Addressability
    Comment: must be addressible at IP layer. Otherwise encryption will not 
    5.1 Notification:
    As pointed out before, the tracing/notification issue is still at an early 
    stage. Following Remarks:
    - hit metering analogy may not be approriate here, content providers might 
    want at least some limited help in the OPES case
    - (out-of-band) notification may be a problem for the recipient if it must  
    handle a lots of notification information. A solution (should 
    notification be needed) would be to perform aggregation. I.e send me a 
    notification every hour rather than for each message.
    5.2 Non-blocking:
    OPES intermediaries MUST support a bypass feature. There is a clear open 
    issue if the OPES service is essential.
    5.3 Privacy.
    From the tracing information, the user can contact the OPES first node, 
    then ask its privacy policy.
    What is not clear nor explicitely stated here is that the first OPES node is 
    not necessarilly addressible. A statement like "at least one trace per 
    domain must identify one addressible node" is needed.
    question : is there any relationship with the ALIAS WG wrt to 
    establishing a trust relationship with an intermediary.
    answer: OPES is application level while ALIAS deals with the transport 


    OCP: OPES callout protocol
    HTTP adaptation with OPES
    Implementation effort
    OPES processor and end points communications
    OPES Treatment of IAB Considerations