2.1.11 Open Pluggable Edge Services (opes)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-06

Chair(s):
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 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.

Deliverables:

- 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.
Done  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.
Internet-Drafts:
  • - 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-02.txt
  • - draft-ietf-opes-end-comm-05.txt
  • - draft-ietf-opes-iab-03.txt
  • - draft-ietf-opes-http-01.txt
  • - draft-ietf-opes-rules-p-02.txt
  • No Request For Comments

    Current Meeting Report

    Open Pluggable Edge Services (OPES)
    58th IETF Meeting
    11 November 2003
    
    Eric Burger, scribe
    
    Jabber log is at
    
    <http://www.xmpp.org/ietf-logs/opes@iet
    f.xmpp.org/2003-11-11.html>
    
    =====
    
    Agenda Bashing: Markus Hofmann
    
    =====
    
    Document Status - See slides & ID Tracker
    
    Goal: finish documents in  "ID Exists" status by end of November
    
    =====
    
    OPES Treatment of IAB Considerations
    
    
    draft-ietf-opes-iab-03 - Abbie Barbir
    
    
    See slides
    
    
    On Considerations 3.1 & 3.2: chose to make notifications optional; focus on 
    tracing.
    
    
    Clearly, OPES cannot do end-to-end encryption.  OPES can do 
    hop-by-hop encryption.
    
    Sally Floyd: Likes document; addresses IAB issues
    
    Markus: expect WGLC soon after IETF
    
    =====
    OPES process and end points communications
    
    
    Draft-ietf-opes-end-comm-05 - Abbie Barbir
    
    
    See slides
    
    
    Tracing
    -------
    
    Open issue: What is OPES Tracing? Current wording has problem with 
    "inclusion".  Does that mean that trace can be adapted (pruned, 
    modified, added-to)?
    
    Should we allow trace adaptation?
    
    Trace information designed for system administrators, not users.
    
    
    Bypass
    ------
    
    IAB Considerations said to bypass non-OPES content.  But, what is OPES 
    content?  Solution: punt -- definition of OPES content is outside scope of 
    OPES.
    
    Sally Floyd: Comment: IAB document isn't legal language. Try to figure out 
    what the intent is. The IAB document does not mean "user has to have a way to 
    bypass firewalls, boundaries, etc."  It is saying, "If a user asks for 
    content from web server, and the content gets mangled by an OPES server, 
    then user needs to be able to figure out what went wrong."
    
    
    MUST/SHOULD/MAY questions: see slides
    
    w.r.t. OPES bypass - Sally Floyd: Source of IAB concern about non-OPES is 
    data integrity, e.g., how does one detect malicious 
    transformation of data.
    
    
    =====
    OPC: OPES Callout Protocol
    
    draft-ietf-opes-ocp-core-03 - Abbie Barbir
    
    see slides
     
    Should authentication be in the core or binding (HTTP)?
    
    Should authentication be in this draft, or a separate draft?
    
    Same issues for Encryption.
    
    Should we get IETF review before going to WGLC?  Marshall: "NO"
    
    Application message identifiers are irrelevant for HTTP, but might not be 
    robust enough for SMTP.  Should we dump them and figure out the right 
    thing for SMTP later, if there is a later?
    
    Markus: Please post comments on AM-ID's to the list!
    
    =====
    HTTP Adaptation with OPES
    
    Draft-ietf-opes-http-01 (from Martin and Alex) presented by Markus
    
    See slides
    
    Targeting WGLC for end of November
    
    Need HTTP expert to review HTTP-specific issues, and in particular on 
    HTTP-specific security considerations
    
    Open issues: How to avoid blocking; skip uninteresting request bodies in 
    'response mode'; and handle HTTP-specific things like 100 Continue and 206 
    Partial Content?
    
    Please check for XXX's in document and send text to mail list!
    
    
    =====
    P: Message Processing Language
    
    Presented by Markus
    
    See slides
    
    Open issues:
    
    What information is available to interpreter? Complete message? Headers 
    only? Punt?
    
    Is doing HTTP module in scope for work group?   If so, in what 
    document?
    
    Should work group define interfaces between P interpreters and module 
    suppliers or callout services?  If so, how do services return results, 
    e.g., from OCP?
    
    Ted Hardie: Working group should specify what information is available to 
    the interpreter.  Not a value judgement of where, just we should set 
    expectations for community.
    
    Ted Hardie: When do we expect the current charter items to be done?
    
    Markus: Hopefully December.
    
    
    =====
    OPES Future
    
    Markus
    
    Note: Re-chartering is ONLY for adding new work items, not for staying 
    alive to do work from old charter.  Keep new work in OPES framework, not 
    something new.
    
    Really need to know who will be committed to working on new work items.
    
    PLEASE POST THOUGHTS AND SUGGESTIONS TO MAIL LIST.  PLEASE VOLUNTEER TO DO 
    WORK!!!
    
    OPES for SMTP and IMAP: does it conflict with lemonade?
    
    Eric Burger: Not at all.  Definitely fits into OPES, just need to 
    coordinate groups.
    
    If you have interest in a topic, want to be an editor or 
    contributor, please post to list.
    
    Marshall: Importance of finishing documents -- "credibility is the coin of 
    the realm." 

    Slides

    Agenda
    OPES Treatment of IAB Considerations
    OPES processor and end points communications
    OCP: OPES callout protocol
    HTTP Adaptation with OPES
    P: Message Processing Language
    OPES WG Future