--- 1/draft-ietf-opes-architecture-02.txt 2006-02-05 00:55:48.000000000 +0100 +++ 2/draft-ietf-opes-architecture-03.txt 2006-02-05 00:55:49.000000000 +0100 @@ -1,27 +1,27 @@ Network Working Group Abbie. Barbir Internet-Draft Nortel Networks -Expires: December 18, 2002 R. Chen +Expires: January 31, 2003 R. Chen AT&T Labs M. Hofmann Bell Labs/Lucent Technologies H. Orman Purple Streak Development R. Penno Nortel Networks G. Tomlinson The Tomlinson Group - June 19, 2002 + August 2, 2002 An Architecture for Open Pluggable Edge Services (OPES) - draft-ietf-opes-architecture-02 + draft-ietf-opes-architecture-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -30,72 +30,71 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on December 18, 2002. + This Internet-Draft will expire on January 31, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines an architecture for a cooperative application service in which a data provider, a data consumer, and zero or more application entities cooperatively realize a data stream service. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Architecture . . . . . . . . . . . . . . . . . . . . . . 4 2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1.1 Data Dispatcher . . . . . . . . . . . . . . . . . . . . . . 5 - 2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . 8 - 2.5 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . 10 - 3. Security and Privacy Considerations . . . . . . . . . . . . 12 - 3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.2 Callout protocol . . . . . . . . . . . . . . . . . . . . . . 13 - 3.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 3.4 Establishing trust . . . . . . . . . . . . . . . . . . . . . 13 - 3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . 14 - 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 - A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 + 2.1.1 Data Dispatcher . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . 7 + 2.5 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . 8 + 3. Security and Privacy Considerations . . . . . . . . . . . . 10 + 3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.2 Callout protocol . . . . . . . . . . . . . . . . . . . . . . 11 + 3.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.4 Establishing trust . . . . . . . . . . . . . . . . . . . . . 11 + 3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . 12 + 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 + A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 17 1. Introduction - When realizing a data stream service between a provider and a + When supplying a data stream service between a provider and a consumer, the need may arise to provision the use of other application entities, in addition to the provider and consumer. For example, some party may wish to customize a data stream as a service to a consumer. The customization step might be based on the - customer's geographical locality (e.g., language) or resource - availability (e.g., display capabilities). + customer's resource availability (e.g., display capabilities). In some cases in may be beneficial to provide a customization service - at network location instead of deploying it at either the provider or - the consumer host. For certain services performed on end-user behalf - this may be the only option of service deployment. In this case, one - or more additional application entities may participate in the data - stream service. There are many possible provisioning scenarios which - make a data stream service attractive. In [1] a description of - several scenarios is provided. + at a network location between the provider and consumer host rather + than at one of these endpoints. For certain services performed on + end-user behalf this may be the only option of service deployment. + In this case, one or more additional application entities may + participate in the data stream service. There are many possible + provisioning scenarios which make a data stream service attractive. + In [1] a description of several scenarios is provided. This document presents the architectural components of Open Pluggable Edge Services (OPES) that are needed in order to perform a data stream service. The architecture addresses the IAB considerations described in [2]. These considerations are covered in the various parts of the document, specifically with respect to tracing (Section 2.5) and security considerations (Section 3). The document is organized as follows: Section 2 introduces the OPES architecture. Section 3 discusses security considerations. Section @@ -112,79 +111,49 @@ o OPES flows: data flows that are cooperatively realized by the OPES entities; and, o OPES rules: these specify when and how to execute OPES intermediary services. 2.1 OPES Entities An OPES entity is an application that operates on a data flow between a data provider application and a data consumer application. OPES - entities can be one of the following: + entities can be: o an OPES service application, which analyzes and possibly transforms messages exchanged between the data provider - application and the data consumer application; or, + application and the data consumer application; o a data dispatcher, which invokes an OPES service application based on OPES ruleset and application-specific knowledge. In the network, OPES entities reside inside OPES processors. The cooperative behavior of OPES entities introduces additional functionality for each data flow provided that it matches the OPES rules. In the current work, the data provider and data consumer applications are not considered as OPES entities. The OPES architecture is largely independent of the protocol that is used by the OPES entities 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. - - --------------------------------------------------------------------- - - +-------------+ - |OPES service | - | Application | - | | - +-------------+ - | Data | - | Dispatcher | - | | - +-------------+ - | | - | HTTP | - | | - +-------------+ - | TCP/IP | - +-------------+ - | ... | - +-------------+ - - Figure 1: OPES Logical Implementation - - --------------------------------------------------------------------- - - Figure 1 depicts a "minimal" stack for OPES. However, other - protocols may be present, depending on the functions that are - performed by the application. + example for the underlying protocol in OPES flows. 2.1.1 Data Dispatcher 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 combined ruleset enables an OPES processor to determine which service applications to invoke for which data flow. Accordingly, the data dispatcher constitutes an enhanced policy enforcement point, where policy rules are evaluated, service-specific data handlers and state - information is maintained, as depicted in Figure 2. + information is maintained, as depicted in Figure 1. --------------------------------------------------------------------- +----------+ | callout | | server | +----------+ || || || @@ -196,21 +165,21 @@ | | appl | || | | +----------+ || | | +----------------------+ | OPES flow <---->| | data dispatcher and | |<----> OPES flow | | policy enforcement | | | +----------------------+ | | OPES | | processor | +--------------------------+ - Figure 2: Data Dispatchers + Figure 1: Data Dispatchers --------------------------------------------------------------------- The architecture allows more than one policy enforcement point to be present on an OPES flow. 2.2 OPES Flows An OPES flow is a cooperative undertaking between a data provider application, a data consumer application, zero or more OPES service @@ -242,158 +211,131 @@ | | | | | | | | | | | | | +----------+ +--------+ | | +--------+ +----------+ | | | TCP/IP | | TCP/IP | | | | TCP/IP | | TCP/IP | | | +----------+ +--------+ | | +--------+ +----------+ | | || || || | | || || || | | ============= ================= ============= | | | | | +------------------------------+ +------------------------------+ | <----------------- OPES flow -----------------> | - Figure 3: An OPES flow + Figure 2: An OPES flow --------------------------------------------------------------------- - Figure 3 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 dispatchers to be present in any flow. 2.3 OPES Rules OPES policy regarding services and the data provided to them is determined by a ruleset consisting of OPES rules. The rules consist of a set of conditions and related actions. The ruleset is the superset of all OPES rules on the processor. The OPES ruleset 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 flows. - 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 and interpreting the ruleset. The OPES architecture does not require a mechanism for configuring a ruleset into a data dispatcher. This 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 revisions of the architecture may introduce such a requirement. 2.4 Callout Servers The evaluation of OPES ruleset determines which service applications will operate on a data stream. How the ruleset is evaluated is not the subject of the architecture, except to note that it must result in the same unambiguous result in all implementations. In some cases it may be useful for the OPES processor to distribute the responsibility of service evaluation by communicating with one or - more callout servers (cf., [7]). The situation is illustrated in - Figure 4, which shows a data dispatcher communicating with multiple - callout servers as it processes an OPES flow. - - --------------------------------------------------------------------- - - data callout callout callout - dispatcher server server server - - +----------+ +---------+ +---------+ +---------+ - | | | | | | | | - | OCP | | OCP | | OCP | ... | OCP | - | | | | | | | | - +----------+ +---------+ +---------+ +---------+ - | Lower | | Lower | | Lower | | Lower | - | Layer | | Layer | | Layer | | Layer | - |Protocols | |Protocols| |Protocols| |Protocols| - | . | | . | | . | | . | - | . | | . | | . | | . | - +----------+ +---------+ +---------+ +---------+ - || || || || - ||================ || ... || - || || || - ||============================== || - || || - ================================================ - - Figure 4: An OPES flow with Callout servers - - --------------------------------------------------------------------- - - In Figure 4, a data dispatcher invokes the services of a callout - server by using the OPES callout protocol (OCP). The requirements - for the OCP are given in [7]. The OCP is application-agnostic, being - unaware of the semantics of the encapsulated application protocol - (e.g., HTTP). However, the OCP must incorporate a service aware - vectoring capability that parses the data flow according to the - ruleset and delivers the data to the OPES service application that - can be local or remote. + more callout servers. A data dispatcher invokes the services of a + callout server by using the OPES callout protocol (OCP). The + requirements for the OCP are given in [7]. The OCP is application- + agnostic, being unaware of the semantics of the encapsulated + application protocol (e.g., HTTP). However, the OCP must + incorporate a service aware vectoring capability that parses the data + flow according to the ruleset and delivers the data to the OPES + service application that 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 5, which illustrates the + interaction situation is depicted in Figure 3, 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 ==== - | +------------+ | + | | service | | +---------------+ +-----------+ + | | appl | | |Callout Server | | Callout | + | +----------+ | | A | | Server | + | || | | +--------+ | | X | + | +----------------------+ | | | OPES | | | | + | | data dispatcher | | | | Service| | | +--------+| + | +----------------------+ | | | App2 | | | | OPES || + | || | | +--------+ | | |Service || + | +-------+ | | || | | | AppX || + | +---------+ | | | | +--------+ | ... | +--------|| + | | HTTP | | OCP |=========| | OCP | | | || | + | +---------| +-------+ | | +--------+ | | +------+ | + | +---------+ || | +---------------+ | | OCP | | + | | | =======================================| | | + | | | | | +------+ | + | | TCP/IP | | | | + =====| | |============== OPES ====== | | + | +---------+ | Data Flow +-----------+ +--------------------------+ - Figure 5: Interaction of OPES Entities + Figure 3: Interaction of OPES Entities --------------------------------------------------------------------- 2.5 Tracing Facility The OPES architecture requires that each data dispatcher to provide tracing facilities that allow the appropriate verification of its operation. The OPES architecture requires that tracing be feasible on the OPES flow per OPES processor using in-band annotation. One - of those annotations could be a URL with more detailed information on + of those annotations could be a URI with more detailed information on the transformation that occurred to the data on the OPES flow. 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. + aware clients and servers. The support of these extensions to the + base protocol HTTP is not required by non-OPES clients and servers. 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 Each data flow must be secured in accordance with several policies. The primary stakeholders are the data consumer and the data provider. The secondary stakeholders are the entities to which they may have delegated their trust. The other stakeholders are the owners of the callout servers. Any of these parties may be participants in the - OPES architecture. + OPES flow. These parties must have a model, explicit or implicit, describing their trust policy; which of the other parties are trusted to operate on data, and what security enhancements are required for communication. The trust might be delegated for all data, or it might be restricted to granularity as small as an application data unit. All parties that are involved in enforcing policies must communicate the policies to the parties that are involved. These parties are @@ -430,23 +372,23 @@ privilege to it. 3.2 Callout protocol The determination of whether or not OPES processors will use the measures that are described in the previous section during their communication with callout servers depends on the details of how the primary parties delegated trust to the OPES processors and the trust relationship between the OPES processors and the callout server. If the OPES processors are in a single administrative domain with strong - confidentiality guarantees, then encryption may be optional. In - other cases, encryption and strong authentication would be at least - strongly recommended. + confidentiality guarantees, then encryption may be optional. + However, it is recommended that for all cases that encryption and + strong authentication be used. If the delegation mechanism names the trusted parties and their privileges in some way that permits authentication, then the OPES processors will be responsible for enforcing the policy and for using authentication as part of that enforcement. The callout servers must be aware of the policy governing the communication path. They must not, for example, communicate confidential information to auxiliary servers outside the trust domain. @@ -497,22 +439,22 @@ Although the architecture supports a wide range of cooperative transformation services, it has few requirements for interoperability. The necessary and sufficient elements are specified in the following documents: o the OPES ruleset schema [6] which defines the syntax and semantics of the rules interpreted by a data dispatcher; and, - o the OPES callout protocol (OCP) [7] which defines the protocol - between a data dispatcher and a callout server. + o the OPES callout protocol (OCP) [7] which defines the requirements + for the protocol between a data dispatcher and a callout server. References [1] McHenry, S., et. al, "OPES Scenarios and Use Cases", Internet- Draft TBD, May 2002. [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.