Current Meeting Report
Slides


2.1.7 Open Pluggable Edge Services (opes)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/30/2002

Chair(s):
Marshall Rose <mrose@dbc.mtview.ca.us>
Markus Hofmann <hofmann@bell-labs.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
P. Faltstrom <paf@cisco.com>
Applications Area Advisor:
Ned Freed <ned.freed@mrochek.com>
Technical Advisor(s):
A. Mankin <mankin@isi.edu>
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:
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
Internet-Drafts:
  • - draft-ietf-opes-architecture-02.txt
  • - draft-ietf-opes-protocol-reqs-01.txt
  • - draft-ietf-opes-scenarios-00.txt
    • No Request For Comments

    Current Meeting Report

     Minutes of the Open Pluggable Edge Services WG (opes)

    Time: Tuesday, 2002-07-16, 1700-1800, room 502
    Chairs: Markus Hofmann, Marshall Rose
    Minutes: Marshall Rose


    1. Introduction, minutes taker, blue sheets

    The chair introduced the agenda, and asked for some to take minutes. A volunteer
    was indentured.


    2. Agenda bashing

    No changes to the agenda were suggested.


    3. Discussion of WG documents

    3a. Abbie Barber presented an overview of the "An Architecture for Open
    Pluggable Edge Services" document (draft-ietf-opes-architecture-02.txt).

    The speaker noted that addressing the IAB architectural considerations document
    (RFC 3238) was the core philosophy for writing this document. As such, the
    speaker examined the architectural document in the context of the individual
    points enumerated in RFC 3238.

    The speaker addressed the current set of issues on the mailing list along with
    the current thinking, and concluded that there weren't any open issues
    remaining... although, some of the more detailed IAB issues are delegated to
    other OPES documents.

    There was concern that the documents didn't adequately differentiate between
    content consumers and providers, and, as such, some issues may be settled in
    ways that may not be appropriate for content consumers, e.g., the architectural
    document introduces the notion of tracing to address some of the IAB issues, but
    a content consumer may not want a content provider to know that the consumer has
    fielded an OPES intermediary. It was agreed that the architectural document
    should be revised to make issues like this more clear.

    3b. The speaker then presented an overview of the "OPES Use Cases and Deployment
    Scenarios" document (draft-ietf-opes-scenarios-00.txt), in particular noting the
    taxonomy of OPES services, and how various scenarios illustrated the requests
    associated with those services.

    The same concern regarding a lack of consumer/provider differentiation was
    raised. In particular, more use cases should be presented with respect to
    tracing. It was noted that this document is written from the perspective of an
    OPES processor, so perhaps this lack of differentiation is appropriate for the
    use cases.

    3c. Markus Hofmann presented an overview of the "Requirements for OPES Callout
    Protocols" document (draft-ietf-opes-protocol-reqs-01.txt).
    The document is strucutred as a checklist, followed by more detailed text
    explaining various requirements.

    Four issues were raised on the mailing list:

    1. Should the draft allow unencrypted communications in the same "trusted"
    domain?

    suggested resolution: yes

    discussion: deciding what "trusted" means is perhaps problematic.

    2. Is an explicit keep-alive mechanism a MUST or a SHOULD requirement, e.g., if
    the protocol has another way of doing this, should this be allowed instead?

    suggested resolution: MUST

    3. Should endpoint authorization information be communicated to the callout
    server, or should the OPES processor be solely responsible for performing
    authorization.

    suggested resolution: allow

    discussion: it is too restricting to prevent callout servers from performing
    authorization. recall the end-to-end problem.

    4. Should chaining allow and specify requirements for chaining?

    suggested resolution: none yet.

    The author reviewed the two IAB issues that are germane to the callout protocol
    requirements draft.

    3e. For these three drafts, the chairs asked the audience to (re-)read them
    carefully and comment to the mailing list, as the next revision of these
    documents will likely be submitted to the IESG for publication as informational
    RFCs. The chairs also noted that the group makes progress in spurts, and that we
    need another growth spurt in order to get these drafts over the wall to the
    IESG.

    There was a second discussion on the impact of the IAB considerations, and
    whether some decisions being made, whilst consistent with the considerations,
    were unfriendly to the market place. It was noted that while "the constitution
    is not a suicide pact", deviations from the IAB considerations need to be
    adequately and convincingly documented.


    4. Next documents to be worked on

    4a. Bindignavile Srinivas presented an discussion of the "Security Threats and
    Risks for OPES" (draft-srinivas-opes-threats-00.txt) document. After reminding
    the audience as to the OPES enviornment, the speaker discussed the security
    threats, particularly in the context of RFC 3238:

    - OPES device false (de)registration

    - OPES device spoofing

    - Replay attack

    - OPES device security during fail-over

    - Message integrity

    - Data Confidentiality

    - Denial of service

    - Repudation

    For each threat, the speaker explained how the threat occurs, the effect, and a
    proposed solution.

    Finally, the speaker suggested this draft, an individual submission, be used as
    the basis of a working group document. The chairs indicated that a subteam will
    be formed to develop a document that's consistent with the existing working
    group documents, and that subteam will take this individual submission as input.


    It was suggested that there is another threat possible, given that
    intermediaries may be used for security purposes (e.g., virus detection), if an
    intermediary is disabled, then content consumers may be at risk.

    If end-to-end encryption is a solution to some of these threats, where are the
    ends? If the content consumer/provider, then what assurance is there that
    modifications made by intermediaries are trustworthy? More work should be spent
    on identifying where the trust relationships are with any end-to-end
    encryptions.

    4b. Markus Hofmann explained the status and next steps for an as-yet-unwritten
    document on "Endpoint Authorization and Enforcement Requirements" that was
    supposed be completed on April 2nd of this year.

    As with the "Security Threats" document, a design team needs to be formed to get
    started on the document. However, we'll need some help from the folks who are
    familiar with the IETF policy framework.

    D E A R S A A G, P L E A S E H E L P


    5. Closing

    Adjourn.


    Slides

    An Architecture for Open Pluggable Edge Services
    OPES Use Cases and Deployment Scenarios
    Requirements for OPES Callout Protocols
    Security Threats and Risks for Open Pluggable Edge Services