Last Modified: 2004-07-01
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.
| 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. | |
| Oct 03 | Consider additional OPES work such as extension to traffic beyond HTTP and RTSP and present new charter to IESG, or conclude working group. |
| RFC | Status | Title |
|---|---|---|
| RFC3752 | I | OPES Use Cases and Deployment Scenarios |
|
=============================================
OPES WG Meeting, August 3, 2004; San Diego, California; IETF 60 --------------------------------------------------------------- Markus Hofmann introduced the new co-chair, Tony Hansen. The agenda was accepted without modification, and Markus Hofmann moved on to the first topic, which was the document status. There are six documents in the RFC editor queue. Two others are awaiting AD followup. Hilarie Orman asked that all authors take time to review the last round of modifications, mostly grammatical, and give their OK to the RFC editor. Markus Hofmann presented the new charter. The two items of work are an OCP profile that handles SMTP messages, and the rules language, which is to be based on the "P" language. Hilarie Orman and others noted that there are other SMTP initiatives within the IETF which might be related to OPES. MARID, MASS, LEMONADE, and FAX were mentioned. Hilarie Orman noted that "endpoint" for a store-and-forward protocol is not as well-defined as it is for client-server protocols and asked that care be taken in looking at the IAB guidance and OPES architectural documents to make sure that SMTP gets appropriate treatment. She also asked that the charter be worded to note that email integrity and privacy were especially appropriate concerns for OCP over SMTP. Abbie Barbir presented a discussion of OCP/SMTP use cases. He noted that one option would be to use MIME body parts to communicate protocol and metadata information between the OPES processor and the callout server. He suggested that such parts could be added to the message, for delivery to the recipient, in order to communicate tracing information. The sender could use this method to communicate bypass information to the OPES processor. Abbie Barbir then presented an overview of the P language. Markus Hofmann noted that P was for invoking services, not for writing the executable part of services. Discussion ensued about how to check that P parameters matched the expectations of the service API. Abbie expressed preference for WSDL for describing the services and their side effects. Hilarie Orman expressed a preference for having P support regular expressions in the lefthand side of rules, and for having P support sequences of services. Markus Hofmann noted that error handling might be difficult. |