draft-ietf-opes-architecture-00.txt   draft-ietf-opes-architecture-01.txt 
Network Working Group Abbie. Barbir Network Working Group Abbie. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: November 1, 2002 R. Chen Expires: December 10, 2002 R. Chen
AT&T Labs AT&T Labs
M. Hofmann M. Hofmann
Bell Labs/Lucent Technologies Bell Labs/Lucent Technologies
H. Orman H. Orman
The Purple Streak Development The Purple Streak Development
R. Penno R. Penno
Nortel Networks Nortel Networks
G. Tomlinson G. Tomlinson
Cacheflow Cacheflow
May 3, 2002 June 11, 2002
An Architecture for Open Pluggable Edge Services (OPES) An Architecture for Open Pluggable Edge Services (OPES)
draft-ietf-opes-architecture-00 draft-ietf-opes-architecture-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 1, 2002. This Internet-Draft will expire on December 10, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This memo defines an architecture for a cooperative application This memo defines an architecture for a cooperative application
service in which a data provider, a data consumer, and zero or more service in which a data provider, a data consumer, and zero or more
application entities cooperatively realize a data stream service. application entities cooperatively realize a data stream service.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Architecture . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Architecture . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . 8 2.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . . 8 2.6 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . . 9
3. Security and Privacy Considerations . . . . . . . . . . . . . 10 3. Security and Privacy Considerations . . . . . . . . . . . . . 11
3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Primary data flow . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Callout protocol . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Callout protocol . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Establishing trust . . . . . . . . . . . . . . . . . . . . . . 12
3.5 Establishing trust . . . . . . . . . . . . . . . . . . . . . . 12 3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . . 13
3.6 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . . 12 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
When realizing a data stream service between a provider and a When realizing a data stream service between a provider and a
consumer, the need may arise to provision the use of other consumer, the need may arise to provision the use of other
application entities, in addition to the provider and consumer. For application entities, in addition to the provider and consumer. For
example, some party may wish to customize a data stream as a service example, some party may wish to customize a data stream as a service
to a consumer, e.g., a service might customize the data based on the to a consumer, e.g., a service might customize the data based on the
customer's geographical locality (e.g., language) or resource customer's geographical locality (e.g., language) or resource
availability (e.g., display capabilities). availability (e.g., display capabilities).
In some cases it may be impossible to offer the customization service In some cases in may be beneficial to provide a customization service
at either the provider or the consumer applications. In this case, at network location instead of deploying it at either the provider or
one or more additional application entities may participate in the the consumer host. For certain services performed on end-user behalf
data stream service. There are many possible provisioning scenarios this may be the only option of service deployment. In this case, one
which make a data stream service attractive. The reader is referred or more additional application entities may participate in the data
to [1] for a description of several scenarios. stream service. There are many possible provisioning scenarios which
make a data stream service attractive. The reader is referred to [1]
for a description of several scenarios.
The document presents the architectural components of Open Pluggable The document presents the architectural components of Open Pluggable
Edge Services (OPES) that are needed in order to perform a data Edge Services (OPES) that are needed in order to perform a data
stream service. The architecture addresses the IAB considerations stream service. The architecture addresses the IAB considerations
described in [2]. These considerations are covered in the various described in [2]. These considerations are covered in the various
parts of the document, specifically with respect to tracing (Section parts of the document, specifically with respect to tracing (Section
2.6) and security considerations (Section 3). 2.6) and security considerations (Section 3).
The document is organized as follows: Section 2 introduces the OPES The document is organized as follows: Section 2 introduces the OPES
architecture. Section 3 discusses security considerations. Section architecture. Section 3 discusses security considerations. Section
skipping to change at page 4, line 29 skipping to change at page 4, line 29
An OPES entity is an application that operates on a data flow between An OPES entity is an application that operates on a data flow between
a data provider application and a data consumer application. OPES a data provider application and a data consumer application. OPES
entities can be one of the following: entities can be one of the following:
o an OPES service application, which analyzes and possibly o an OPES service application, which analyzes and possibly
transforms messages exchanged between the data provider transforms messages exchanged between the data provider
application and the data consumer application; or, application and the data consumer application; or,
o a data dispatcher, which invokes an OPES service application based o a data dispatcher, which invokes an OPES service application based
on filtering rules and application-specific knowledge. on OPES ruleset and application-specific knowledge.
In the network, OPES entities reside inside OPES processors. The In the network, OPES entities reside inside OPES processors. The
cooperative behavior of OPES entities introduces additional cooperative behavior of OPES entities introduces additional
functionality for each data flow provided that it matches the OPES functionality for each data flow provided that it matches the OPES
rules. rules.
The OPES architecture is largely independent of the protocol that is In the current work, the data provider and data consumer applications
used by the OPES entities to exchange data. However, this document are not considered as OPES entities. The OPES architecture is
selects HTTP [4] as the example protocol to be used for realizing a largely independent of the protocol that is used by the OPES entities
data flow. In this regard, the "protocol" stack of an OPES entity is to exchange data. However, this document selects HTTP [4] as the
example protocol to be used for realizing a data flow. In this
regard, the logical implementation stack of an OPES entity is
summarized in Figure 1. summarized in Figure 1.
--------------------------------------------------------------------- ---------------------------------------------------------------------
OPES entity +-------------+
|OPES service |
| Application |
| |
+-------------+
| Data |
| Dispatcher |
| |
+-------------+ +-------------+
| | | |
| HTTP | | HTTP |
| | | |
+-------------+ +-------------+
| TCP/IP | | TCP/IP |
+-------------+ +-------------+
| ... | | ... |
+-------------+ +-------------+
Figure 1: An OPES protocol stack Figure 1: OPES Logical Implementation
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 1 depicts a "minimal" stack for OPES. However, other Figure 1 depicts a "minimal" stack for OPES. However, other
protocols may be present, depending on the functions that are protocols may be present, depending on the functions that are
performed by the application. performed by the application.
2.2 OPES Flows 2.2 OPES Flows
An OPES flow is a cooperative undertaking between a data provider An OPES flow is a cooperative undertaking between a data provider
application, a data consumer application, one or more OPES service application, a data consumer application, zero or more OPES service
applications, and one or more data dispatchers. applications, and zero or more data dispatchers.
In order to understand the trust relationships between OPES entities, In order to understand the trust relationships between OPES entities,
each is labeled as residing in an administrative domain. However, each is labeled as residing in an administrative domain. Entities
depending on provisioning decisions, the entities associated with a associated with a given OPES flow may reside in one or more
given OPES flow may reside in one or more administrative domains. administrative domains.
For example, Figure 2 depicts a data flow (also known as an "OPES For example, Figure 2 depicts a data flow (also known as an "OPES
flow"), that spans two administrative domains. flow"), that spans two administrative domains.
--------------------------------------------------------------------- ---------------------------------------------------------------------
consumer administrative domain provider administrative domain consumer administrative domain provider administrative domain
+------------------------------+ +------------------------------+ +------------------------------+ +------------------------------+
| | | | | | | |
| data OPES | | OPES data | | data OPES | | OPES data |
skipping to change at page 6, line 40 skipping to change at page 6, line 40
Figure 2: An OPES flow Figure 2: An OPES flow
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 2 depicts two data dispatchers that are present in the OPES Figure 2 depicts two data dispatchers that are present in the OPES
flow. However, the architecture allows for zero or more data flow. However, the architecture allows for zero or more data
dispatchers to be present in any flow. dispatchers to be present in any flow.
2.3 OPES Rules 2.3 OPES Rules
The behavior of data dispatchers is governed by a set of filtering OPES policy regarding services and the data provided to them is
rules, consisting of a set of conditions and related actions. The determined by a ruleset consisting of OPES rules. The rules consist
ruleset is the superset of all OPES rules on the processor. Data of a set of conditions and related actions. The ruleset is the
dispatchers invoke OPES service applications that may perform superset of all OPES rules on the processor. The OPES ruleset
modifications on an OPES flow. In this model, all data filters are determines which service applications will operate on a data stream.
The communication of data stream elements to an application is
performed by data dispatchers. In this model, all data filters are
invoked for all data. invoked for all data.
In order to ensure predictable behavior the OPES architecture In order to ensure predictable behavior the OPES architecture
requires the use of a standardized schema for the purpose of defining requires the use of a standardized schema for the purpose of defining
and interpreting the ruleset. The OPES architecture does not require and interpreting the ruleset. The OPES architecture does not require
a mechanism for configuring a ruleset into a data dispatcher. This a mechanism for configuring a ruleset into a data dispatcher. This
is treated as a local matter for each implementation (e.g., through is treated as a local matter for each implementation (e.g., through
the use of a text editor, secure upload protocol, and so on). Future the use of a text editor, secure upload protocol, and so on). Future
revisions of the architecture may introduce such a requirement. revisions of the architecture may introduce such a requirement.
2.4 Callout Servers 2.4 Callout Servers
The OPES ruleset is executed within a data dispatcher, which triggers The evaluation of OPES ruleset determines which service applications
the execution of local OPES service applications. How the ruleset is will operate on a data stream. How the ruleset is evaluated is not
executed is not the subject of the architecture. However, in some the subject of the architecture, except to note that it must result
cases it may be useful for the OPES processor to distribute the in the same unambiguous result in all implementations.
responsibility of service execution by communicating with one or more
callout servers (cf., [7]). The situation is illustrated in Figure In some cases it may be useful for the OPES processor to distribute
3, which shows a data dispatcher communicating with multiple callout the responsibility of service evaluation by communicating with one or
servers as it processes an OPES flow. more callout servers (cf., [7]). The situation is illustrated in
Figure 3, which shows a data dispatcher communicating with multiple
callout servers as it processes an OPES flow.
--------------------------------------------------------------------- ---------------------------------------------------------------------
+----------+ +---------+ +---------+ +---------+ data callout callout callout
| data | | callout | | callout | | callout | dispatcher server server server
|dispatcher| | server | | server | | server |
+----------+ +---------+ +---------+ +---------+ +----------+ +---------+ +---------+ +---------+
| | | | | | | | | | | | | | | |
| OCP | | OCP | | OCP | ... | OCP | | OCP | | OCP | | OCP | ... | OCP |
| | | | | | | | | | | | | | | |
+----------+ +---------+ +---------+ +---------+ +----------+ +---------+ +---------+ +---------+
| TCP/IP | | TCP/IP | | TCP/IP | | TCP/IP | | TCP/IP | | TCP/IP | | TCP/IP | | TCP/IP |
+----------+ +---------+ +---------+ +---------+ +----------+ +---------+ +---------+ +---------+
|| || || || || || || ||
||================ || ... || ||================ || ... ||
|| || || || || ||
skipping to change at page 8, line 6 skipping to change at page 8, line 10
In Figure 3, a data dispatcher invokes the services of a callout In Figure 3, a data dispatcher invokes the services of a callout
server by using the OPES callout protocol (OCP). The requirements server by using the OPES callout protocol (OCP). The requirements
for the OCP are given in [7]. The OCP is application-agnostic, being for the OCP are given in [7]. The OCP is application-agnostic, being
unaware of the semantics of the encapsulated application protocol unaware of the semantics of the encapsulated application protocol
(e.g., HTTP). However, the OCP must incorporate a service aware (e.g., HTTP). However, the OCP must incorporate a service aware
vectoring capability that parses the data flow according to the vectoring capability that parses the data flow according to the
ruleset and delivers the data to the OPES service application that ruleset and delivers the data to the OPES service application that
can be local or remote. can be local or remote.
In this model, OPES applications may be executed either on the same
processor (or even in the same application environment) with the
dispatcher or on a different OPES processor through OCP. The general
interaction situation is depicted in Figure 4, which illustrates the
positions and interaction of different components of OPES
architecture.
---------------------------------------------------------------------
+--------------------------+
| +----------+ |
| | OPES | |
| | service | | +----------------+
| | appl | | | Callout Server |
| +----------+ | | |
| || | | +--------+ |
| +----------------------+ | | | OPES | |
| | data dispatcher | | | | Service| |
| +----------------------+ | | | App2 | |
| | HTTP | OCP | | | +--------+ |
| +------------| |==========| OCP | |
| | |---------+ | | +--------+ |
| | TCP/IP | | +----------------+
=========| |=============== OPES Data Flow ====
| +------------+ |
+--------------------------+
Figure 4: Interaction of OPES Entities
---------------------------------------------------------------------
2.5 Policy Enforcement 2.5 Policy Enforcement
Data dispatchers include a ruleset that can be compiled from several Data dispatchers include a ruleset that can be compiled from several
sources and must resolve into an unambiguous result. The compiled sources and must resolve into an unambiguous result. The compiled
ruleset enables an OPES processor to detremine which service ruleset enables an OPES processor to determain which service
applications to invoke for which data flow. Accordingly, the data applications to invoke for which data flow. Accordingly, the data
dispatcher consitutes an enhanced Policy Enforcement Point (PEP), dispatcher constitutes an enhanced Policy Enforcement Point (PEP),
where policy rules are executed, data vectoring and connection where policy rules are evaluated, service-specific data handlers and
management is performed, and service-specific data handlers and state state information are maintained, as depicted in Figure 5.
information are maintained, as depicted in Figure 4.
--------------------------------------------------------------------- ---------------------------------------------------------------------
+----------+ +----------+
| callout | | callout |
| server | | server |
+----------+ +----------+
|| ||
|| ||
|| ||
skipping to change at page 8, line 40 skipping to change at page 9, line 31
| | service | || | | | service | || |
| | appl | || | | | appl | || |
| +----------+ || | | +----------+ || |
| +----------------------+ | | +----------------------+ |
OPES flow <---->| | data dispatcher/PEP | | <----> OPES flow OPES flow <---->| | data dispatcher/PEP | | <----> OPES flow
| +----------------------+ | | +----------------------+ |
| OPES | | OPES |
| processor | | processor |
+--------------------------+ +--------------------------+
Figure 4: Data Dispatchers and Policy Enforcement Point Figure 5: Data Dispatchers and Policy Enforcement Point
--------------------------------------------------------------------- ---------------------------------------------------------------------
The architecture allows more than one PEP to be present on an OPES The architecture allows more than one PEP to be present on an OPES
flow. flow.
2.6 Tracing Facility 2.6 Tracing Facility
The architecture makes no requirements as to how an OPES flow is The architecture makes no requirements as to how an OPES flow is
negotiated, provided that it is consistent with the security policy negotiated, provided that it is consistent with the security policy
(Section 3) of each administrative domain that hosts the OPES (Section 3) of each administrative domain that hosts the OPES
entities that are associated with the flow. entities that are associated with the flow.
The OPES architecture requires that each data dispatcher provides The OPES architecture requires that each data dispatcher provides
tracing facilities that allow the appropriate verification of its tracing facilities that allow the appropriate verification of its
operation. The OPES architecture requires that tracing be feasible operation. The OPES architecture requires that tracing be feasible
on the OPES flow per OPES processor using in-band annotation through on the OPES flow per OPES processor using in-band annotation. One
header extensions on the application protocol that is used (e.g., of those annotations could be a URL with more detailed information on
HTTP). One of those annotations could be a URL with more detailed the transformation that occurred to the data on the OPES flow.
information on the transformation that occurred to the data on the
OPES flow. Future revisions of the architecture may provide for a Future revisions of the architecture may provide for a tracing
tracing facility to be used for subsequent out-of-band analysis. facility to be used for subsequent out-of-band analysis.
Providing the ability for in-band annotation MAY require header
extensions on the application protocol that is used (e.g., HTTP).
However, the presence of an OPES processor in the data request/
response flow SHALL NOT interfere with the operations of non-OPES
aware clients and servers. OPES processors, content server and
content consumer MAY use OPES extensions to the base protocol (HTTP),
but support of these extensions SHALL NOT be required.
OPES processors must obey tracing, reporting and notification
requirements set by the center of authority in the trust domain to
which OPES processor belongs. As part of these requirements OPES
processor may be instructed to reject or ignore such requirements
that originate from other trust domains.
3. Security and Privacy Considerations 3. Security and Privacy Considerations
Each data flow must be secured in accordance with several policies. Each data flow must be secured in accordance with several policies.
The primary stakeholders are the data consumer and the data provider. The primary stakeholders are the data consumer and the data provider.
The secondary stakeholders are the entities to which they may have The secondary stakeholders are the entities to which they may have
delegated their trust. The other stakeholders are the owners of the delegated their trust. The other stakeholders are the owners of the
callout servers. Any of these parties may be participants in the callout servers. Any of these parties may be participants in the
OPES architecture. OPES architecture.
skipping to change at page 10, line 34 skipping to change at page 11, line 34
In order to delegate fine-grained trust, the parties must convey In order to delegate fine-grained trust, the parties must convey
policy information by implicit contract, by a setup protocol, by a policy information by implicit contract, by a setup protocol, by a
dynamic negotiation protocol, or in-line with application data dynamic negotiation protocol, or in-line with application data
headers. headers.
3.1 Trust Domains 3.1 Trust Domains
The delegation of authority starts at either a data consumer or data The delegation of authority starts at either a data consumer or data
provider and moves to more distant entities in a "stepwise" fashion. provider and moves to more distant entities in a "stepwise" fashion.
Stepwise means A delegates to B and B delegates to C and so force. Stepwise means A delegates to B and B delegates to C and so forth.
The entities thus "colored" by the delegation are said to form a The entities thus "colored" by the delegation are said to form a
trust domain with respect to the original delegating party. Here, trust domain with respect to the original delegating party. Here,
"Colored" means that if the first step in the chain is the data "Colored" means that if the first step in the chain is the data
provider, then the stepwise delegation "colors" the chain with that provider, then the stepwise delegation "colors" the chain with that
data "provider" color. The only colors that are defined are data the data "provider" color. The only colors that are defined are the data
"provider" and the data "consumer". An OPES processor may be in "provider" and the data "consumer". Delegation of authority
several trust domains at any time. There is no restriction on (coloring) propagates from the content producer start of authority or
whether the OPES processors are authorized by data consumers and/or from the content consumer start of authority, that may be different
data providers. The original party has the option of forbidding or from the end points in the data flow.
limiting redelegation.
An OPES processor may be in several trust domains at any time. There
is no restriction on whether the OPES processors are authorized by
data consumers and/or data providers. The original party has the
option of forbidding or limiting redelegation.
An OPES processor must have a representation of its trust domain An OPES processor must have a representation of its trust domain
memberships that it can report in whole or in part for tracing memberships that it can report in whole or in part for tracing
purposes. It must include the name of the party which delegated each purposes. It must include the name of the party which delegated each
privilege to it. privilege to it.
3.2 Primary data flow 3.2 Callout protocol
The primary data flow occurs between the data provider and the data
consumer. OPES must not interfere with the capability of these
parties to use end-to-end authentication and confidentiality.
If the primary parties want the assurance that their data does not
appear in plaintext on network links, but they will permit use of
plaintext on OPES processors and/or callout servers, then the OPES
processors must use authentication and encryption between "hops".
A separate security association must be used for each channel
established between two OPES processors.
3.3 Callout protocol
The determination of whether or not OPES processors will use the The determination of whether or not OPES processors will use the
measures that are described in the previous section during their measures that are described in the previous section during their
communication with callout servers depends on the details of how the communication with callout servers depends on the details of how the
primary parties delegated trust to the OPES processors and the trust primary parties delegated trust to the OPES processors and the trust
relationship between the OPES processors and the callout server. If relationship between the OPES processors and the callout server. If
the OPES processors are in a single administrative domain with strong the OPES processors are in a single administrative domain with strong
confidentiality guarantees, then encryption may be optional. In confidentiality guarantees, then encryption may be optional. In
other cases, encryption and strong authentication would be at least other cases, encryption and strong authentication would be at least
strongly recommended. strongly recommended.
skipping to change at page 11, line 45 skipping to change at page 12, line 32
The callout servers must be aware of the policy governing the The callout servers must be aware of the policy governing the
communication path. They must not, for example, communicate communication path. They must not, for example, communicate
confidential information to auxiliary servers outside the trust confidential information to auxiliary servers outside the trust
domain. domain.
A separate security association must be used for each channel A separate security association must be used for each channel
established between an OPES processor and a callout server. The established between an OPES processor and a callout server. The
channels must be separate for different primary parties. channels must be separate for different primary parties.
3.4 Privacy 3.3 Privacy
Some data from data consumers is considered "private" or "sensitive", Some data from data consumers is considered "private" or "sensitive",
and OPES processors must both advise the primary parties of the their and OPES processors must both advise the primary parties of the their
privacy policy and respect the policies of the primary parties. The privacy policy and respect the policies of the primary parties. The
privacy information must be conveyed on a per-flow basis. privacy information must be conveyed on a per-flow basis.
The callout servers must also participate in handling of private The callout servers must also participate in handling of private
data, and they must be prepared to announce their own capabilities data, and they must be prepared to announce their own capabilities
and to enforce the policy required by the primary parties. and to enforce the policy required by the primary parties.
3.5 Establishing trust 3.4 Establishing trust
The OPES processor will have configuration policy specifying what The OPES processor will have configuration policy specifying what
privileges the callout servers have and how they are to be privileges the callout servers have and how they are to be
identified. This is especially critical for third-party (fourth- identified. This is especially critical for third-party (fourth-
party, etc.) callout servers. OPES uses standard protocols for party, etc.) callout servers. OPES uses standard protocols for
authenticating and otherwise security communication with callout authenticating and otherwise security communication with callout
servers. servers.
An OPES processor will have a trusted method for receiving An OPES processor will have a trusted method for receiving
configuration information such as rules for the data dispatcher, configuration information such as rules for the data dispatcher,
trusted callout servers, primary parties that opt-in or opt-out of trusted callout servers, primary parties that opt-in or opt-out of
individual services, etc. individual services, etc.
3.6 End-to-end Integrity 3.5 End-to-end Integrity
Digital signature techniques can be used to mark data changes in such Digital signature techniques can be used to mark data changes in such
a way that a third-party can verify that the changes are or are not a way that a third-party can verify that the changes are or are not
consistent with the originating party's policy. This requires an consistent with the originating party's policy. This requires an
inline manner of specifying policy and its binding to data, a trace inline manner of specifying policy and its binding to data, a trace
of changes and the party making the changes, and strong identities of changes and the party making the changes, and strong identities
and authentication methods. and authentication methods.
Strong end-to-end integrity can fulfill some of the functions Strong end-to-end integrity can fulfill some of the functions
required by "tracing". required by "tracing".
skipping to change at page 16, line 8 skipping to change at page 17, line 8
EMail: rpenno@nortelnetworks.com EMail: rpenno@nortelnetworks.com
Gary Tomlinson Gary Tomlinson
Cacheflow Cacheflow
EMail: gary@tomlinsongroup.net EMail: gary@tomlinsongroup.net
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors gratefully acknowledge the contributions of: Marshall T. The authors gratefully acknowledge the contributions of: Marshall T.
Rose. (more to come, soon...) Rose, John Morris, Oskar Batuner, Mark Baker and Ian Cooper.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/