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.
| 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 |
Current Meeting Report
Minutes of the OPES Meeting at IETF53
=====================================
Wednesday, 3/20/02, 1300-1500
Chairs: Markus Hofmann, Marshall Rose
AD: Ned Freed
Advisors: Hilarie Orman, Allison Mankin
Minutes: Marshall Rose
- Agenda bashing - Markus Hofmann
A discussion on VPCN is not on the agenda due to lack of time. Abbie Barbier will host an informal discussion after the meeting concludes.
No other comments, or changes to the agenda.
- Charter walk-through - Markus Hofmann
The final charter was presented for remedial purposes. The key points:
- both server-centric and client-centric issues are in scope
- endpoints must be able to determine that an intermediary was involved in a communication, so transparent services are not in scope
- regardless, the endpoint's determination of an intermediary needn't occur as a part of the original communication.
- endpoints must be able to bypass the opes service, if desired ("opes must be reversible")
- specification of an opes policy framework is not in scope; however, reuse of an existing framework is acceptable
- limited to use for HTTP and RTP/RTSP
-- Discussion:
Ned Freed suggests that the "work item" text in the charter that says:
Define policy specification method(s) and rules for controlling execution of OPES services
may be revised to avoid confusion with earlier text in the charter, a prohibition on developing a policy frameworks.
- Discussion of workplan, milestones, and how we want to get there - Hofmann
The wg's milestones are timely. In order to continue forward movement, some editing teams will be formed to work on documents in parallel, with their results being given back to the wg
- Architecture: Barbier, Chen, Condry, Penno, Tomlinson
- Scenarios: Chen, Condry, McHenry, Penno, Tomlinson
- E2E Integrity: Orman, Cooper?
- Protocol Requirements: Beck, Penno
- Threat Model: TBD
- Endpoint authorization/enforcement: TBD
Given the dependency hierarchy of the documents, the chairs will be initially focusing their efforts on developing the first two documents.
- Disussion on the end-to-end integrity and encryption compatibility issue for proposal to the ADs - Hilarie Orman
Although the IAB is asking if OPES can be compatible with e2e-encryption, a more general question is whether OPES can provide confidentiality.
As a first principle, OPES will not transparently insert itself in an e2e-connection. However, if an OPES service offers something of value to the endpoints, then an endpoint may choose to trust an OPES intermediary in order to access that service. Adding more parties (e.g., when the intermediary invokes a callout server) introduces more complexity.
This raises some questions:
- should OPES support concatented confidential links?
- how are confidentiality requirements communicated?
- in what configurations should confidentiality be perpetuated?
-- Discussion:
- multiparty key management is very hard
- an explicit trust model is superior to an implicit trust model
- encryption and integrity are seperate functions, although the same technologies may be used to achieve both tasks
- perhaps a new model is needed to relate intermediaries and endpoints to clarify these issues
- if opes is to provide confidentiality, it can do so only between each application hop (e.g., between the origin client and an intermediary), and not between the origin client and origin server (as the intermediaries need plaintext access to the data. independent of confidentiality, message integrity can be used to allow the origin client and server to examine the original data and any intermediary transformations.
- Discussion of next WG documents
For all documents, it is noted that volunteers are still welcome to join the editing teams.
-- Scenario document, presented by Abbie Barber
Still fluid, large changes in the works:
- Remove business case text
- new discussion on the applicability of callout servers
- new taxonomy of services: on requests, responses, or taking a request to generate a response.
-- Architecture document, presented by Abbie Barber
Major emphasis on addressing issues presented in RFC 3238. Progress being made on several fronts; however, many open questions require a protocol "fix", perhaps one of:
- some new HTTP extensions (headers, methods, etc.)
- some new markup tags
- a OPES signalling protocol
--- Discussion:
- must be sensitive to embedding literal addresses (ipv4/ipv6)
- must also be sensitive to the interaction with authoring tools.
in particular, authoring programs (WebDAV clients) use the GET request (just like a browser) to retrieve a page for editing. accordingly, an intermediary must not alter the content being transfered for the purpose of authoring. at least one authoring product includes a proprietary header in the GET request to indicate that the client is in "authoring mode". Similarly, Section 14.9.5 of RFC 2616 also provides a "No-Transform" directive in the HTTP response for this purpose.
-- Callout protocol/tracing requirements, presented by Andre Beck
Current draft is based on pre-charter OPES and was heavily influenced on existing callout protocols. As such, some early assumptions may no longer be valid.
The authors suggest that the existing draft be an input to the wg, but not as a starting point for the working group's deliverable.
--- Discussion:
- what does it mean to "bypass" an OPES service: just bypassing one intermediary or all of them?
- what about performance? should there be requirements to optimize this?
-- Callout protocol/tracing requirements, part deux, presented by Abbie Barber
The authors suggest a new approach: consider requirements without being influenced by existing callout protocols.
In particular, what about these requirements: flow control, failover, capability negotiation, NATs/firewalls, and so on.
--- Discussion:
- what about interaction with the webi and cgi working groups?
- what about using soap or web services? -- really should be requirements driven before picking a particular protocol
-- Endpoint authorization and enforcement document, presented by Lee Rafalow
Other groups are working on web services-based workflow, can opes use this work?
Since an authorization model for setting policies is required we also need an authentication model. There's also the need for an authentication and authorization model vis-a-vis the policy owner and a called service.
RFC 3238 has some impact on the document, but a full review hasn't been completed yet. Regardless, one key issue is the need for policy to control notifications suggested in the IAB guidelines.
--- Discussion:
- the "general" issue is that the origin server doesn't see what the originally client actually asked, nor does the origin client see what the origin server actually responded with.
-- Threat/risk model document, discussed by Markus Hofmann
To repeat, for all documents, it is noted that volunteers are still welcome to join the editing teams.
Slides
IAB Architectural Consideration for OPES
OPES and E2E Encryption
OPES Policy Considerations
Requirements for OPES Callout Protocols
OPES Callout Protocol Requirements
OPES Scenarios