Last Modified: 2003-02-19
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. | |
| JAN 03 | Submit document on endpoint authorization and enforcement requirements to IESG for Informational. | |
| JAN 03 | Submit document on threat/risk model for OPES services to IESG for Informational. | |
| MAY 03 | Initial protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization. | |
| MAY 03 | Initial document on rules specification method. | |
| JUL 03 | Submit protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization to IESG for Proposed Standard. | |
| JUL 03 | Submit document on rules specification method to IESG for Proposed Standard. | |
| JUL 03 | Consider additional OPES work such as extension to traffic beyond HTTP and RTSP and present new charter to IESG, or conclude working group. |
Tue Mar 18 11:24:33 2003 - 56th IETF WG: Open Pluggable Edge Services (opes) Chairs: Markus Hofmann Marshall T. Rose Monday, March 17th, 2003 15:30-17:30 US/Pacific Minutes by: Marshall T. Rose Markus: Agenda Introduction: Status of WG documents Start on OPES protocol work - Introduction to protocol Protocol work - Protocol layer and the OPES callout protocol - OPES scope clarifications - Major decision points for protocol design - OPES protocol pre-draft thoughts General Discussion - Thoughts on SOAP/XML Open Discussion Markus: Any changes to the agenda? none. Markus: Status of WG documents OPES architecture: approved for publication as informational OPES protocol requirements: approved for publication as informational OPES policy and authorization: being reviewed by the IESG OPES threats and risks: being reviewed by the IESG OPES use and scenarios: being reviewed by the IESG in conjunction with threats/risks document (but ID-tracker is out-of-date) Markus: Start on OPES protocol work What needs to be done: work on two-related items! - OPES callout protocol - Relationship to application message protocols To date, good progress on fundamental design issues, but we need to work more on: - relationship to application message protocol - tracing/debugging considerations - security considerations Start with a discussion of major decision points that affect the core protocol design, e.g., - what type of interactions need to be supported (e.g., strict request/reply or one request with multiple replies or ... - what type of data is exchanged Then we can design the fundamental protocol mechanisms/messages in a generic format. Then we can talk about specific protocol bindings/mappings The callout protocol SHOULD be application-agnostic, but MUST do HTTP. Things to keep in mind: - we are working within the OPES architecture - any deviations must be conscious and within the charter - be specific on new "requirements" and why? - stick to the terminology in the existing wg documents - always keep in mind the IAB considerations Abbie: OPES Scope Clarifications (or open questions) Can OPES change the final destination of an application message? - If yes: what opes agents can do that and what techniques are allowed? - If no: can generating a response w/o forwarding the request be considered a form of redirection? Can OPES agents communicate with data provider/consumer using application protocols? Can OPES fan-out messages? Can OPES aggregate messages? Can OPES provide protocol translation service? Questions: Alex: how do we answer these questions? Ned: first, get concensus that you want to do things like these, and also look at your charter. Make sure there's demand for it... Alex: is a specific use case enough to justify going forward with something? Ned: if there's clear buyin from the working group, yes? Alex: but isn't there a conflict in terms of concensus for optional things? Ned: keep in mind that implementors need to provide a general implementation... Ned: i'll check with Allison and Sally about some of these issues. Hilarie: Protocol Layering and the OPES callout protocol One way to look at the architecture: Application Extension OPES Callout Protocol Application ] proxy Appication Transport ] Network The challenge is to provide a seemless application extension. Keith: why is this desirable? it's hard to make do protocol semantics. it's too hard to build a generic extensible proxy. Hilarie: there is experience showing how to do this. [ note: hilarie has some very nice diagrams that i can't render here... ] Summarizing, this architecture let's us understand where various capabilities fit in. Questions: Keith: perhaps you can generalize payload transformations, but what is very difficult to do is take protocol-specific things like email headers, http response codes, and try to build generic protocol transformations for those. Hilarie: the next speaker will address how to specify content modifications Ned: even mapping just content types is hard, e.g., when you have to go one-to-many or many-to-one. Alex: can an OPES cloud server generate a response? Hilarie: yes, because proxies can have colocated services like caches, so they can answer directly Alex: but isn't that redirection? Hilarie: no, not really. Alex: if you let an OPES server generate a response, then it can pretty much do whatever it wants. Hilarie: allowing the OPES processor unlimited communications violates the privacy considerations. Ned: the big issue deals with enforcement, we need to be able to deflect abuse by limiting the way things can be configured. this reinforces hilarie's point with respect to limiting the scope. Abbie: can we trust the rule-writer to write rules that won't break the rules Alex: Major decision points for protocol design Current decision points will be discussed today. Future decision points (that we won't discuss): - transport binding - message binding - application protocol binding - error handling What can talk first? - OPES dispatcher is a client, so should always talk first - specific roles simplify protocol - however: - callout server may next extra info - keep-alive violates simple roles - feature negotaiton may violate simple roles Keith: Trying to generalize a single layer that can handle handle generic application transformations is not possible. Are responses required, optional, or not allowed? - require responses only if they carry important info - add optional ACKs for debugging? - send an ACK when draining a buffer Keith: you'll always need an ACK indicating success or failure Granularity: addressable data parts - "entire message" is simple but inefficient - "sequential bytes" don't let us skip stuff - "sequential bytes with gaps" assume serialized application - arbitrary bytes" is flexible but may be inneficient - we support the most flexible scheme, but implementations use application-specific scheme Copy or move data to the other side? - Move is simpler and uses less storage on dispatcher, but copy allows the callout server get out of the loop, and the dispather may need copy anyway. - make optional, and requires servers to declare Can OPES mesages be given a handling priority? - not required - perhaps an optional optimization Consult the pre-draft document for a discussion of protocol operation Abbie: Thoughts on Soap/XML Why consider SOAP? - can still design an efficient callout protocol using soap (e.g., with a fixed parse tree) - can have access to any published service - facilities for security, privacy, policy exchange - why do we need another service-oriented protocol? Keith: it's too early to ask the question, also, is rpc a good mechanism for callouts? Alex: but does SOAP address/interact with IAB considerations? Abbie: i don't think this is an issue Keith: are there really many useful services around that would be helpful to OPES? Markus: adjourn. |