2.1.10 Open Pluggable Edge Services (opes)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-19

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>
Patrik Faltstrom <paf@cisco.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 distribution.

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 endpoint.

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.
JAN 03  Submit document on endpoint authorization and enforcement requirements to IESG for Informational.
JAN 03  Submit document on threat/risk model for OPES services to IESG for Informational.
MAY 03  Initial protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization.
MAY 03  Initial document on rules specification method.
JUL 03  Submit protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization to IESG for Proposed Standard.
JUL 03  Submit document on rules specification method to IESG for Proposed Standard.
JUL 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-ops-rfc2786std-00.txt
  • - draft-ietf-opes-authorization-02.txt
  • - draft-ietf-opes-threats-02.txt
  • No Request For Comments

    Current Meeting Report

    Tue Mar 18 11:24:33 2003 - 56th IETF
    WG: Open Pluggable Edge Services (opes)
    Chairs: Markus Hofmann
            Marshall T. Rose
    Monday, March 17th, 2003 15:30-17:30 US/Pacific
    Minutes by: Marshall T. Rose
    Markus: Agenda
        Status of WG documents
        Start on OPES protocol work
            - Introduction to protocol
        Protocol work
            - Protocol layer and the OPES callout protocol
            - OPES  scope clarifications
            - Major decision points for protocol design
            - OPES protocol pre-draft thoughts
        General Discussion
            - Thoughts on SOAP/XML
        Open Discussion
        Any changes to the agenda? none.
    Markus: Status of WG documents
        OPES architecture: approved for publication as informational
        OPES protocol requirements:  approved for publication as 
        OPES policy and authorization: being reviewed by the IESG
        OPES threats and risks: being reviewed by the IESG
        OPES use and scenarios: being reviewed by the IESG in 
    conjunction with threats/risks document (but ID-tracker is 
    Markus: Start on OPES protocol work
        What needs to be done: work on two-related items!
            - OPES callout protocol
            - Relationship to application message protocols
        To date, good progress on fundamental design issues, but we need to 
    work more on:
            - relationship to application message protocol
            - tracing/debugging considerations
            - security considerations
        Start with a discussion of major decision points that affect the core 
    protocol design, e.g.,
            - what type of interactions need to be supported (e.g., strict 
    request/reply or one request with multiple replies or ...
            - what type of data is exchanged
        Then we can design the fundamental protocol 
    mechanisms/messages in a generic format.
        Then we can talk about specific protocol bindings/mappings
        The callout protocol SHOULD be application-agnostic, but MUST do HTTP.
        Things to keep in mind:
            - we are working within the OPES architecture
            - any deviations must be conscious and within the charter
            - be specific on new "requirements" and why?
            - stick to the terminology in the existing wg documents
            - always keep in mind the IAB considerations
    Abbie: OPES Scope Clarifications (or open questions)
        Can OPES change the final destination of an application message?
            - If yes: what opes agents can do that and what techniques are 
            - If no: can generating a response w/o forwarding the request be 
    considered a form of redirection?
        Can OPES agents communicate with data provider/consumer using 
    application protocols?
        Can OPES fan-out messages?
        Can OPES aggregate messages?
        Can OPES provide protocol translation service?
        Alex: how do we answer these questions?
        Ned: first, get concensus that you want to do things like these, and 
    also look at your charter. Make sure there's demand for it...
        Alex: is a specific use case enough to justify going forward with 
        Ned: if there's clear buyin from the working group, yes?
        Alex: but isn't there a conflict in terms of concensus for optional 
        Ned: keep in mind that implementors need to provide a general 
        Ned: i'll check with Allison and Sally about some of these issues.
    Hilarie: Protocol Layering and the OPES callout protocol
        One way to look at the architecture:
            Application Extension
                OPES Callout Protocol
            Application               ] proxy
            Appication Transport      ]
        The challenge is to provide a seemless application extension.
        Keith: why is this desirable? it's hard to make do protocol 
    semantics. it's too hard to build a generic extensible proxy.
        Hilarie: there is experience showing how to do this.
        [ note: hilarie has some very nice diagrams that i can't render 
    here... ]
        Summarizing, this architecture let's us understand where various 
    capabilities fit in.
        Keith: perhaps you can generalize payload transformations, but what is 
    very difficult to do is take protocol-specific things like email 
    headers, http response codes, and try to build generic protocol 
    transformations for those.
        Hilarie: the next speaker will address how to specify content 
        Ned: even mapping just content types is hard, e.g., when you have to go 
    one-to-many or many-to-one.
        Alex: can an OPES cloud server generate a response?
        Hilarie: yes, because proxies can have colocated services like 
    caches, so they can answer directly
        Alex: but isn't that redirection?
        Hilarie: no, not really.
        Alex: if you let an OPES server generate a response, then it can 
    pretty much do whatever it wants.
        Hilarie: allowing the OPES processor unlimited communications 
    violates the privacy considerations.
        Ned: the big issue deals with enforcement, we need to be able to 
    deflect abuse by limiting the way things can be configured. this 
    reinforces hilarie's point with respect to limiting the scope.
        Abbie: can we trust the rule-writer to write rules that won't break the 
    Alex: Major decision points for protocol design
        Current decision points will be discussed today.
        Future decision points (that we won't discuss):
            - transport binding
            - message binding
            - application protocol binding
            - error handling
        What can talk first?
            - OPES dispatcher is a client, so should always talk first
            - specific roles simplify protocol
            - however:
                - callout server may next extra info
                - keep-alive violates simple roles
                - feature negotaiton may violate simple roles
        Keith: Trying to generalize a single layer that can handle handle 
    generic application transformations is not possible.
        Are responses required, optional, or not allowed?
            - require responses only if they carry important info
            - add optional ACKs for debugging?
            - send an ACK when draining a buffer
        Keith: you'll always need an ACK indicating success or failure
        Granularity: addressable data parts
            - "entire message" is simple but inefficient
            - "sequential bytes" don't let us skip stuff
            - "sequential bytes with gaps" assume serialized application
            - arbitrary bytes" is flexible but may be inneficient
            - we support the most flexible scheme, but 
    implementations use application-specific scheme
        Copy or move data to the other side?
            - Move is simpler and uses less storage on dispatcher, but copy 
    allows the callout server get out of the loop, and the dispather may need 
    copy anyway.
            - make optional, and requires servers to declare
        Can OPES mesages be given a handling priority?
            - not required
            - perhaps an optional optimization
        Consult the pre-draft document for a discussion of protocol 
    Abbie: Thoughts on Soap/XML
        Why consider SOAP?
            - can still design an efficient callout protocol using soap 
    (e.g., with a fixed parse tree)
            - can have access to any published service
            - facilities for security, privacy, policy exchange
            - why do we need another service-oriented protocol?
        Keith: it's too early to ask the question, also, is rpc a good 
    mechanism for callouts?
        Alex: but does SOAP address/interact with IAB 
        Abbie: i don't think this is an issue
        Keith: are there really many useful services around that would be 
    helpful to OPES?
    Markus: adjourn.


    Open Pluggable Extension Services - General
    Callout Protocol Design: Major Decision Points
    OPES Callout Protocol Scope Clarifications
    OPES Callout Protocol: SOAP Consideration