Open Pluggable Edge Services (opes) ----------------------------------- Charter Last Modified: 2006-12-29 Current Status: Active Working Group Chair(s): Tony Hansen Markus Hofmann Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Ted Hardie Technical Advisor(s): Allison Mankin Hilarie Orman Mailing Lists: General Discussion:ietf-openproxy@imc.org To Subscribe: ietf-openproxy-request@imc.org Archive: http://www1.ietf.org/mail-archive/web/newtrk/current/ 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. 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. Done Consider additional OPES work such as extension to traffic beyond HTTP and RTSP and present new charter to IESG, or conclude working group. Done Submit document on OCP/SMTP profile for MTAs, including mechanisms for tracing and bypass, to IESG for Proposed Standard. Done 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). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2006 Feb 2007 Integrity, privacy and security in OPES for SMTP Request For Comments: RFC Stat Published Title ------- -- ----------- ------------------------------------ RFC3752 I Apr 2004 OPES Use Cases and Deployment Scenarios RFC3835 I Sep 2004 An Architecture for Open Pluggable Edge Services (OPES) RFC3836 I Sep 2004 Requirements for OPES Callout Protocols RFC3837 I Sep 2004 Security Threats and Risks for Open RFC3838 I Sep 2004 Policy, Authorization and Enforcement Requirements of OPES RFC3897 I Sep 2004 OPES entities and end points communication RFC3914 I Oct 2004 OPES Treatment of IAB Considerations RFC4037Standard Mar 2005 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core RFC4236Standard Nov 2005 HTTP Adaptation with Open Pluggable Edge Services (OPES) RFC4496 I May 2006 Open Pluggable Edge Services (OPES) SMTP Use Cases