Current Meeting Report
Slides
2.1.7 Open Pluggable Edge Services (opes)
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.
Last Modifield: 05/30/2002
Chair(s):
Marshall Rose <mrose@dbc.mtview.ca.us>
Markus Hofmann <hofmann@bell-labs.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
P. Faltstrom <paf@cisco.com>
Applications Area Advisor:
Ned Freed <ned.freed@mrochek.com>
Technical Advisor(s):
A. Mankin <mankin@isi.edu>
Hilarie Orman <ho@alum.mit.edu>
Mailing Lists:
General Discussion: ietf-openproxy@imc.org
To Subscribe: ietf-openproxy-request@imc.org
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
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.
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 |
Internet-Drafts:
- draft-ietf-opes-architecture-02.txt
- draft-ietf-opes-protocol-reqs-01.txt
- draft-ietf-opes-scenarios-00.txt
No Request For Comments
Current Meeting Report
Minutes of the Open Pluggable Edge Services WG (opes)
Time: Tuesday, 2002-07-16, 1700-1800, room 502
Chairs: Markus Hofmann, Marshall Rose
Minutes: Marshall Rose
1. Introduction, minutes taker, blue sheets
The chair introduced the agenda, and asked for some to take minutes. A volunteer
was indentured.
2. Agenda bashing
No changes to the agenda were suggested.
3. Discussion of WG documents
3a. Abbie Barber presented an overview of the "An Architecture for Open
Pluggable Edge Services" document (draft-ietf-opes-architecture-02.txt).
The speaker noted that addressing the IAB architectural considerations document
(RFC 3238) was the core philosophy for writing this document. As such, the
speaker examined the architectural document in the context of the individual
points enumerated in RFC 3238.
The speaker addressed the current set of issues on the mailing list along with
the current thinking, and concluded that there weren't any open issues
remaining... although, some of the more detailed IAB issues are delegated to
other OPES documents.
There was concern that the documents didn't adequately differentiate between
content consumers and providers, and, as such, some issues may be settled in
ways that may not be appropriate for content consumers, e.g., the architectural
document introduces the notion of tracing to address some of the IAB issues, but
a content consumer may not want a content provider to know that the consumer has
fielded an OPES intermediary. It was agreed that the architectural document
should be revised to make issues like this more clear.
3b. The speaker then presented an overview of the "OPES Use Cases and Deployment
Scenarios" document (draft-ietf-opes-scenarios-00.txt), in particular noting the
taxonomy of OPES services, and how various scenarios illustrated the requests
associated with those services.
The same concern regarding a lack of consumer/provider differentiation was
raised. In particular, more use cases should be presented with respect to
tracing. It was noted that this document is written from the perspective of an
OPES processor, so perhaps this lack of differentiation is appropriate for the
use cases.
3c. Markus Hofmann presented an overview of the "Requirements for OPES Callout
Protocols" document (draft-ietf-opes-protocol-reqs-01.txt).
The document is strucutred as a checklist, followed by more detailed text
explaining various requirements.
Four issues were raised on the mailing list:
1. Should the draft allow unencrypted communications in the same "trusted"
domain?
suggested resolution: yes
discussion: deciding what "trusted" means is perhaps problematic.
2. Is an explicit keep-alive mechanism a MUST or a SHOULD requirement, e.g., if
the protocol has another way of doing this, should this be allowed instead?
suggested resolution: MUST
3. Should endpoint authorization information be communicated to the callout
server, or should the OPES processor be solely responsible for performing
authorization.
suggested resolution: allow
discussion: it is too restricting to prevent callout servers from performing
authorization. recall the end-to-end problem.
4. Should chaining allow and specify requirements for chaining?
suggested resolution: none yet.
The author reviewed the two IAB issues that are germane to the callout protocol
requirements draft.
3e. For these three drafts, the chairs asked the audience to (re-)read them
carefully and comment to the mailing list, as the next revision of these
documents will likely be submitted to the IESG for publication as informational
RFCs. The chairs also noted that the group makes progress in spurts, and that we
need another growth spurt in order to get these drafts over the wall to the
IESG.
There was a second discussion on the impact of the IAB considerations, and
whether some decisions being made, whilst consistent with the considerations,
were unfriendly to the market place. It was noted that while "the constitution
is not a suicide pact", deviations from the IAB considerations need to be
adequately and convincingly documented.
4. Next documents to be worked on
4a. Bindignavile Srinivas presented an discussion of the "Security Threats and
Risks for OPES" (draft-srinivas-opes-threats-00.txt) document. After reminding
the audience as to the OPES enviornment, the speaker discussed the security
threats, particularly in the context of RFC 3238:
- OPES device false (de)registration
- OPES device spoofing
- Replay attack
- OPES device security during fail-over
- Message integrity
- Data Confidentiality
- Denial of service
- Repudation
For each threat, the speaker explained how the threat occurs, the effect, and a
proposed solution.
Finally, the speaker suggested this draft, an individual submission, be used as
the basis of a working group document. The chairs indicated that a subteam will
be formed to develop a document that's consistent with the existing working
group documents, and that subteam will take this individual submission as input.
It was suggested that there is another threat possible, given that
intermediaries may be used for security purposes (e.g., virus detection), if an
intermediary is disabled, then content consumers may be at risk.
If end-to-end encryption is a solution to some of these threats, where are the
ends? If the content consumer/provider, then what assurance is there that
modifications made by intermediaries are trustworthy? More work should be spent
on identifying where the trust relationships are with any end-to-end
encryptions.
4b. Markus Hofmann explained the status and next steps for an as-yet-unwritten
document on "Endpoint Authorization and Enforcement Requirements" that was
supposed be completed on April 2nd of this year.
As with the "Security Threats" document, a design team needs to be formed to get
started on the document. However, we'll need some help from the folks who are
familiar with the IETF policy framework.
D E A R S A A G, P L E A S E H E L P
5. Closing
Adjourn.
Slides
An Architecture for Open Pluggable Edge Services
- Abbie Barbir
- Robin Chen
- Markus Hofmann
- Hilarie Orman
- Reinaldo Penno
OPES Use Cases and Deployment Scenarios
- Abbie Barbir
- Eric Burger
- Robin Chen
- Stephen McHenry
- Hilarie Orman
- Reinaldo Penno
Requirements for OPES Callout Protocols
- Andre Beck
- Markus Hofmann
- Hilarie Orman
- Reinaldo Penno
- Andreas Terzis
Security Threats and Risks for Open Pluggable Edge Services