Subject: WG ACTION: Open Pluggable Edge Services (opes)

From: The IESG <[email-masked]>
Date: Fri, 22 Feb 2002 18:02:01 -0500

A new working group has been formed in the Applications Area of the IETF.
For additional information, contact the Area Directors
or the WG Chair.

Open Pluggable Edge Services (opes)
-----------------------------------

 Current Status: Active Working Group
 
 Chair(s):
     Markus Hofmann <[email-masked]>
 
 Applications Area Director(s): 
     Ned Freed  <[email-masked]>
     Patrik Faltstrom  <[email-masked]>
 
 Applications Area Advisor: 
     Ned Freed  <[email-masked]>
  Technical Advisor(s):
     Allison Mankin  <[email-masked]>
     Hilarie Orman  <[email-masked]>
 
 Mailing Lists: 
     General Discussion:[email-masked]
     To Subscribe:      [email-masked]
     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 framework must 
require that provisioning of OPES services be explicitly authorized by 
at least one 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.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 framework must 
require that provisioning of OPES services be explicitly authorized by 
at least one 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.
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 framework must 
require that provisioning of OPES services be explicitly authorized by 
at least one 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