2.1.9 Open Pluggable Edge Services (opes)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-18

Chair(s):

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

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <shollenbeck@verisign.com>

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 2004  Revised document on OPES rules language.
Done  Submit use cases document for OPES services operating on SMTP to IESG for Informational.
Done  Initial document on OCP/SMTP profile for MTAs, including mechanisms for tracing and bypass.
Apr 2005  Submit document on OCP/SMTP profile for MTAs, including mechanisms for tracing and bypass, to IESG for Proposed Standard.
Jun 2005  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 2005  Submit document(s) on OPES rules language to IESG for Proposed Standard.
Jul 2005  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-http-03.txt
  • draft-ietf-opes-smtp-use-cases-04.txt
  • draft-ietf-opes-smtp-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
    RFC4037 Standard Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core

    Current Meeting Report

     
    OPES Working Group
Chairs: Tony Hansen and Markus Hofmann

Meeting started at 19:00, November 8, 2005.

Agenda overview. No issues.

Review of existing RFCs. The internet draft smtp-use-cases draft has been
updated to address required revisions and will be resubmitted.

Milestones review. Because it has languished with no one willing to work
on it, the rules language milestones are being removed from the charter. 
This has been submitted to the IESG. The IESG has not approved this yet, 
but this will be on the agenda of the next telechat.

Paul Knight did a presentation entitled "SMTP adaptation with OPES",
authored by Martin Stecher and Clemenss Perz, about the draft authored
by the same people. This started with a quick review of OPES services
and how this work relates to the charter of the working group. He
explained that the HTTP profile and the OCP core are completed RFCs,
and that the SMTP profile is the area now being focused on.

Tracing and bypass were called out as issues that need to be addressed 
in the SMTP profile. Paul showed a diagram showing a typical message 
path, with an MUA --> MSA --> MTA --> MTA --> MTA --> MDA --> MUA. The 
diagram indicated that the OCP/SMTP callout to a callout server would 
happen at the MTA points in the message path. Blake Ramsdell pointed 
out that the other points in the chain could be reasonable places to 
use the OCP/SMTP callout also. John Leslie pointed out that the MSA 
operates on SMTP, so logically it seems that OCP/SMTP would be reasonable 
to apply at that point, and that the MDA to MUA protocol is not SMTP, 
so it is not likely to be useful. The WG chairs concurred. [N.B. The 
MSA will use either SMTP, Submit (which is a restricted SMTP), or a 
non-SMTP-based protocol. The first two could be subject to OCP/SMTP.]

John Leslie pointed out that the example OPES-* headers in the example 
provided by Paul were not before the Received header for the MTA. 
Philip Guenther pointed out that one of the OPES-System simply needed 
to be reordered before the bottom Received header. The relevance of 
this is that the ordering of the headers is important in order to show 
which MTA applied the headers, which seems to be an issue that needs 
to be understood. The WG chairs pointed out that doing this also 
requires that the definition of "Trace headers" as defined by 2821/2822 
be expanded to include the OPES-* trace headers.

Paul covered tracing and notifications to "the sender", and John pointed 
out that the "sender of the message" is somewhat ambiguous (MAIL FROM, 
Sender, Reply-To, etc. etc.) The WG chairs indicated that the WG needs 
to explore the meaning following the spirit of the IAB considerations. 
Ted Hardie pointed out that the semantic of sender is "TBD", but that 
following the spirit of the IAB considersions it should most likely be 
interpreted as "the creator of content" (just as in the HTTP case, for 
which the IAB considerations were written). Barry Leiba pointed out that 
Joe-jobs are another potential concern.

The WG charis pointed out a concern that "bypass" in the context of SMTP 
is problematic. The essence is that "bypass" means that the sender and 
recipient have the ability to opt-out. So how should this be enforced? 
Paul pointed out that you do not have an option to bypass virus scanning 
services, for instance. The WG chairs indicated that the WG needs to 
determine how the IAB considerations apply to the SMTP case and that early 
dialog with the authors of the IAB considerations would be helpful to 
ensure the WG is on the right track.

Paul continued speaking about bypass issues, as there is some ambiguity 
as to what the "sender" or "recipient" in the context of SMTP. Is an MTA 
communicating with the next downstream MTA considered to be a "sender"? 
Paul indicated that these concerns are already spelled out in the existing 
draft.

Philip Guenther pointed out that the IAB considerations might not have 
considered SMTP as a protocol when coming up with their list of requirements 
for OPES, and that push vs. pull models. He suggested that really pushing 
the IAB to reconsider their recommendations to consider SMTP-specific 
issues might be useful. The WG chair indicated that the original 
considerations were written mostly with HTTP in mind, but that a dialog 
with the IAB about SMTP could very well be helpful. Philip pointed out 
that the tracing is meant to provide a mechanism to indicate "blame" so 
you know what intermediate OPES agent to be angry at.

The general way that this is going to proceed is that issues with bypass 
and tracing that are hard to deal with between the SMTP profile and the 
IAB considerations would be discussed informally with the IAB members. 
The theory is that in IESG last call, the IAB will review the document 
and there should be no surprises.

The WG chair pointed out that the working group progress on the drafts 
needs to have more participation from the SMTP community. If there is no 
discussion, then there isn't any real reason to keep the working group 
active, and there could be the risk of simply shutting it down.

The mailing list address is ietf-openproxy@imc.org.

The meeting adjourned at 19:45.

    Slides

    Status of WG Documents and Milestones, Next Steps
    SMTP Adaptation with OPES