2.1.8 Open Pluggable Edge Services (opes)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-07

Chair(s):

Tony Hansen <tony@att.com>
Markus Hofmann <hofmann@bell-labs.com>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.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 improve the
user experience. Web proxies, for example, are commonly deployed to
provide services such as Web caching, virus scanning, and request
filtering. Lack of standardized mechanisms to trace and to control
such intermediaries causes problems with respect to failure
detection, data integrity, privacy, and security.

The OPES Working Group has previously developed an architectural
framework to authorize, invoke, and trace such application-level
services for HTTP. The framework follows a one-party consent model,
which requires that each service be authorized explicitly by at least
one of the application-layer endpoints. It further requires that OPES
services are reversible by mutual agreement of the application
endpoints.

In particular, the WG has developed a protocol suite for invocation
and tracking of OPES services inside the net. The protocol suite
includes a generic, application-agnostic protocol core (OCP Core)
that is supplemented by profiles specific to the application-layer
protocol used between the endpoints. So far, the WG has specified an
OCP profile for HTTP, which supports OPES services that operate on
HTTP messages.

In a next step, the WG will specify one or more OCP profiles that
will support OPES services operating on SMTP. In particular, the
profile to be specified will enable an SMTP server (the OPES
processor) to encapsulate and forward SMTP data and metadata to a
callout server for additional processing. Several kinds of agents
participate in SMTP exchanges, including MSA, MTA, MDA, and MUA. The
first OCP/SMTP profile will address the needs of at least the MTA
and/or MDA. More profiles may be needed to address other
agent-specific needs, such as for LMTP and/or SUBMIT. The security
and privacy concerns of SMTP must be carefully analyzed as part of
the definition of the profile.

In addition, the WG will define a rules language to control selection
and invocation of services by an OPES processor. This includes a
mechanism allowing an OPES processor to perform a runtime check of
service parameters, leveraging existing interface description
standards like WSDL, if possible, or OPES-specific description
otherwise. Defining language(s) for implementing OPES services is out
of the WG scope. The rules language will be based on previous work of
the WG on a rules language named "P". The WG will have a design goal
that the language 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. It
will be out of scope for this WG to develop the policy framework and
specify multiple-endpoint policy distribution.

The group's new work items can be listed as:

- Develop a document about "Scenarios and Use Cases for
OPES Services operating on SMTP".
- Define profile(s) for OCP core that handle SMTP messages
or parts thereof.
- Define a rules language to control the selection and
invocation of HTTP-based or SMTP-based OPES services.

Each deliverable must follow the previously developed OPES
architecture. As each deliverable is developed, it must address the
IAB considerations specified in RFC 3238.

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.
Done  Submit protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization to IESG for Proposed Standard.
Nov 04  Revised document on OPES rules language.
Dec 04  Submit use cases document for OPES services operating on SMTP to IESG for Informational.
Feb 05  Initial document on OCP/SMTP profile for MTAs, including mechanisms for tracing and bypass.
Apr 05  Submit document on OCP/SMTP profile for MTAs, including mechanisms for tracing and bypass, to IESG for Proposed Standard.
Jun 05  Submit document(s) on OCP/SMTP profile(s) for those other SMTP agents the WG has decided to work on, if any, to IESG as Proposed Standard(s).
Jul 05  Submit document(s) on OPES rules language to IESG for Proposed Standard.
Jul 05  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-ocp-core-05.txt
  • draft-ietf-opes-http-02.txt
  • draft-ietf-opes-smtp-use-cases-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC3752 I OPES Use Cases and Deployment Scenarios
    RFC3835 I An Architecture for Open Pluggable Edge Services (OPES)
    RFC3836 I Requirements for OPES Callout Protocols
    RFC3837 I Security Threats and Risks for Open
    RFC3838 I Policy, Authorization and Enforcement Requirements of OPES
    RFC3897 I OPES entities and end points communication
    RFC3914 I OPES Treatment of IAB Considerations

    Current Meeting Report

     
    OPES WG Meeting, March 8, 2004; Minneapolis, MN, USA; IETF 62
-------------------------------------------------------------

- agenda bashing
   - status, milestones
   - discussion of SMTP use cases
   - next steps
 - WG status
   - 7 RFCs published
   - one in rfc editor queue
   - one AD followup
   - one I-D being worked on: smtp-use-cases
     - goal to finish with next 1-2 weeks
 - milestones
   - falling behind on OPES rules language
   - ditto on SMTP uses cases
   - cannot start OCP/SMTP profile until use cases done
 - SMTP use cases (presented by Paul Knight)
   - as always, more input, especially substantive, would be good
   - overview of draft and OPES use
     - desire to provide interoperability
     - desire to use callout servers with different app. protocols
   - for SMTP, OPES is focused on (hanging off) the MTA
     - Philip: pointer to Crocker's arch doc should be used/added
     - Randy: are intermediate MTAs truly appropriate?
     - Newman: yes: enterprises need to do filtering at their gateways
     - Rob: don't bother flagging as sane; each site may need to make its own guarantees
     - Keith Moore: need tracing info; extreme care in all modifications; multiple modifications are likely to interact poorly
     - Markus: tracing will be addressed according to IAB considerations
   - activation points
     - look appropriate
       - as SMTP server
       - as SMTP client
     - look inappropriate
       - on queued mail
     - but it really is appropriate as there is an envelope context and there are reasons to scan messages in the queue
       - as SMTP proxy
   - SMTP callout modes
     - command modification
     - command satisfaction (catch request and supply reply)
     - reply modification
     - message modification
   - use cases
     - three groups:
       - command modification
     - some similar to HTTP use cases (RFC 3752)
     - virus scanning, spam filtering, verify S/MIME signatures
       - command satisfaction
     - logging or validating MAIL FROM or RCPT TO addresses
       - OPES mail delivery side effects
     - reject a message whose content violates a possible trigger condition
     - delay a message, change queues
     - generate additional notification messages
   - modifications
     - callout servers need more context
       - Newman, Moore: modifying protocol as wrong model consent issues on changes
       - Freed: interest in modifying parameters to commands (change DSN parameters)
     - use cases may preclude each other
     - where are the administrative boundaries
     - goal: message modifications need to move as close to sender as they have the most information
       - ...but you can't cross boundaries
     - milter as model/example
   - Open issues:
     - can't treat satisfaction as modification, as some commands change state
     - legal restrictions on modification?
       - responsibility moves at acceptance
     - if called post-acceptance, how to reflect back into the SMTP world
     - monkeying with signed messages causes problems
       - Moore: 822 model as permitting additions to headers, but not modifications to content; and the IETF does not bless the evil already done by SMTP servers
     - timeout prevention methods?
     - trust issues?
     - IAB considerations, privacy considerations, etc
   - Discussion:
    - Moore: OPES should be closed down: SMTP work not driven by people who know SMTP
    - Freed: need to start with _useful_ use cases, got to winnow down your scope
    - Moore: no problem with that
    - Markus: Need to re-focus use cases document to discuss specific scenarios; helps setting the scope
    - Guenther: current document is list of tools for attacking problems; should start with use cases and figure out needed tools from there

    Slides

    Agenda
    OPES SMTP Use Cases