Current Meeting Report
Jabber Logs

2.1.11 Open Pluggable Edge Services (opes)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/30/2002

Marshall Rose <>
Markus Hofmann <>
Applications Area Director(s):
Ned Freed <>
Patrik Faltstrom <>
Applications Area Advisor:
Ned Freed <>
Technical Advisor(s):
A. Mankin <>
Hilarie Orman <>
Mailing Lists:
General Discussion:
To Subscribe:
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:
APR 02  Submit OPES scenarios document and architecture document to IESG for Informational.
APR 02  Submit document on protocol (callout and tracing) requirements to IESG for Informational.
APR 02  Submit document on endpoint authorization and enforcement requirements to IESG for Informational.
APR 02  Submit document on threat/risk model for OPES services to IESG for Informational.
JUL 02  Initial protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization
SEP 02  Consider additional OPES work such as extension to traffic beyond HTTP and RTSP and present new charter to IESG, or conclude working group.
SEP 02  Submit protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization to IESG for Proposed Standard
  • - draft-ietf-opes-architecture-03.txt
  • - draft-ietf-opes-protocol-reqs-02.txt
  • - draft-ietf-opes-scenarios-01.txt
  • No Request For Comments

    Current Meeting Report

    Monday, November 18 at 1300-1500
    CHAIRS: Marshall Rose <>
       	Markus Hofmann <>
    - Introduction, minutes taker, blue sheets
    Marshall Rose to take minutes.
    - Agenda bashing
    No comments.
    - Discussion of WG documents
      - Status of documents submitted to IESG (hofmann)
          - draft-ietf-opes-scenarios-00.txt
          - draft-ietf-opes-architecture-02.txt
        The design teams met to address the IESG comments. Markus 
    enumerated the issues, along with the suggested approach.
        Channels in the callout protocol: why are they there? they 
    introduce security issues. They deal with state, but aren't clearly 
    (enough) described.
        How many OPES callout protocols are there? How do you pick which one? 
    There is one, but you can negotiate parameters when using it.
        More comments will be sent to mailing list/authors!
      - Security Threats and Risks for Open Pluggable Edge Services 
          - draft-ietf-opes-threats-00.txt
        Top-level taxonomy: in-band (datastream) and out-of-band 
    (otherwise) threats.
        In-band threats: fundamentally, have to use hop-by-hop security to deal 
    with opes flow network/application level threats. Authorization is also a 
    large issue.
        Out-of-band threats: caused by weakness in implementation.
        There are other types of DOS besides overloading.
        The notion of "key manipulation" is puzzling. Why would an 
    encrypted link have a generic threat in this area? It is not 
    necessarily the case that keys will be sent across OPES, besides the 
    notion of key distribution is out of scope.
        A reminder: we must focus only on threats introduced by OPES.
      - Requirements for Policy, Authorization and Enforcement of OPES 
    Services (beck)
        Top-level taxonomy: requirements for opes policy architecture and opes 
    service authorization
        Reminder: look for a common solution to these requirements, instead of 
    trying to come up with a specific solution.
        Does it matter if the intermediary is acting on behalf of the client or 
    the origin server?  Technically, no, in the sense that the 
    requirements deal with OPES endpoints. Further, conflicting rules from 
    different endpoints have to be dealt with, but that the actual 
    algorithm for conflict resolution is out of scope for OPES.
    - Summary and wrap up of the ICAP discussion to accompany possible 
    informational publication of that protocol (berzau)
          - draft-elson-icap-01.txt
          - draft-stecher-opes-icap-eval-00.txt
        The ICAP I-D is an individual specification that will be published as an 
    RFC to document current practice.
        First there was ICAP 0.9, then 0.95, then 1.0 (Summer, 2001) which is 
    stable and deployed. Various issues have arisen as a result of this 
        What about the "it's an RFC" problem? There's the "IESG note" to 
    clarify the relationship of the draft to the standards track.
    - Next WG items to be worked on (hofmann)
      - OPES protocol
        Either we identify an existing protocol and declare victory, or we 
    modify an existing protocol, or we create a new one.
        There are lots of things to choose from: HTTP, ICAP, SOAP, BEEP, etc., 
        Given the group's metabolism, have to be careful in terms of 
    allocating resources.  Let's start with the OPES Callout Protocol 
    Requirements draft.
        Also include the OPES Policy/Authorization draft as a part of this.    
      - Methods for specification of rules/policies (beck)
        How much can we learn from similar IETF efforts (e.g., CPL)?
        Also, what about IRML (an older individual I-D submission)? Is this a 
    good start?
        Perhaps, but there are a lot of uses to be considered.
        Do we need more detailed requirements for a specification 
    language? Perhaps this falls out of the policy requirements draft, 
    (implying that we need to put more details into the policy 
    requirements drafts, rather than having a separate document).
    - Adjourn.


    Status of Documents submitted to IESG
    Requirements for Policy, Authorization and Enforcement of OPES Services
    Summary of the ICAP Discussion
    Next WG Items to be worked on
    Specification of OPES Rules/Policies
    Security Issues in OPES - Threats and Risks