From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3752.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc3752.txt (limited to 'doc/rfc/rfc3752.txt') diff --git a/doc/rfc/rfc3752.txt b/doc/rfc/rfc3752.txt new file mode 100644 index 0000000..db7ddb4 --- /dev/null +++ b/doc/rfc/rfc3752.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group A. Barbir +Request for Comments: 3752 Nortel Networks +Category: Informational E. Burger + Brooktrout Technology, Inc. + R. Chen + AT&T Labs + S. McHenry + Individual Contributor + H. Orman + Purple Streak Development + R. Penno + Nortel Networks + April 2004 + + + Open Pluggable Edge Services (OPES) + Use Cases and Deployment Scenarios + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This memo provides a discussion of use cases and deployment scenarios + for Open Pluggable Edge Services (OPES). The work examines services + that could be performed to requests and/or responses. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Types of OPES services . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Services performed on requests . . . . . . . . . . . . . 3 + 2.1.1. Services intending to modify requests . . . . . 3 + 2.1.2. Services *not* intending to modify requests . . 4 + 2.2. Services performed on responses. . . . . . . . . . . . . 4 + 2.2.1. Services intending to modify responses . . . . . 4 + 2.2.2. Services *not* intending to modify responses . . 5 + 2.3. Services creating responses. . . . . . . . . . . . . . . 5 + 3. OPES deployment scenarios . . . . . . . . . . . . . . . . . . 5 + 3.1. Surrogate Overlays . . . . . . . . . . . . . . . . . . . 6 + 3.2. Delegate Overlays . . . . . . . . . . . . . . . . . . . 7 + + + +Barbir, et al. Informational [Page 1] + +RFC 3752 OPES Scenarios April 2004 + + + 3.3. Enterprise environment . . . . . . . . . . . . . . . . . 8 + 3.4. Callout Servers . . . . . . . . . . . . . . . . . . . . 9 + 3.5. Chaining of OPES data filters and callout servers . . . 9 + 3.5.1. Chaining along the content path. . . . . . . . . 9 + 3.5.2. Chaining along the callout path. . . . . . . . . 9 + 4. Failure cases and service notification . . . . . . . . . . . . 10 + 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 11 + 6. Informative References . . . . . . . . . . . . . . . . . . . . 11 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 + 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 + +1. Introduction + + The Open Pluggable Edge Services (OPES) [1] architecture enables + cooperative application services (OPES services) between a data + provider, a data consumer, and zero or more OPES processors. The + application services under consideration analyze and possibly + transform application-level messages exchanged between the data + provider and the data consumer. The execution of such services is + governed by a set of filtering rules installed on the OPES processor. + + The rules enforcement can trigger the execution of service + applications local to the OPES processor. Alternatively, the OPES + processor can distribute the responsibility of service execution by + communicating and collaborating with one or more remote callout [6] + servers. + + The document presents examples of services in which Open Pluggable + Edge Services (OPES) would be useful. There are different types of + OPES services: services that modify requests, services that modify + responses, and a special case of the latter, services that create + responses. + + The work also examines various deployment scenarios of OPES services. + The two main deployment scenarios, as described by the OPES + architecture [1], are surrogate overlays and delegate overlays. + Surrogate overlays act on behalf of data provider applications, while + delegate overlays act on behalf of data consumer applications. The + document also describes combined surrogate and delegate overlays, as + one might find within an enterprise deployment. + + The document is organized as follows: Section 2 discusses the various + types of OPES services. Section 3 introduces OPES deployment + scenarios. Section 4 discusses failure cases and service + notification. Section 5 discusses security considerations. + + + + + +Barbir, et al. Informational [Page 2] + +RFC 3752 OPES Scenarios April 2004 + + + The IAB has expressed architectural and policy concerns [2] about + OPES. Other OPES documents that may be relevant are, "OPES Service + Authorization and Enforcement Requirements" [5]. See references [3, + 4] for recommended background reading. + +2. Types of OPES services + + OPES scenarios involve services that can be performed on requests for + data and/or responses. OPES services can be classified into three + categories: services performed on requests, services performed on + responses, and services creating responses. In Figure 1, the four + service activation points for an OPES processor are depicted. The + data dispatcher examines OPES rules, enforces policies, and invokes + service applications (if applicable) at each service activation + point. + + +------------------------------------------------+ + | +-------------+-------------+ | + | | Service Application | | + | +---------------------------+ | + Responses | Data Dispatcher | Responses + <============4== +---------------------------+ <=3=========== + Requests | HTTP | Requests + =============1=> +---------------------------+ ==2==========> + | OPES Processor | + +------------------------------------------------+ + + Figure 1: Service Activation Points + +2.1. Services performed on requests + + An OPES service performed on HTTP requests may occur when a request + arrives at an OPES processor (point 1) or when it is about to leave + the OPES processor (point 2). + + The services performed on requests can further be divided into two + cases: those that intend to modify requests and those that do not. + +2.1.1. Services intending to modify requests + + An OPES processor may modify a service request on behalf of the data + consumer for various reasons, such as: + + o Owner of a Web access device might need control over what kind of + Web content can be accessed with the device, parental control for + example. + + o Organization may restrict or redirect access to certain web + + + +Barbir, et al. Informational [Page 3] + +RFC 3752 OPES Scenarios April 2004 + + + services based on various criteria such as time of the day or the + employee access privileges. + + o Hiding the data consumer's identity, user agent, or referrer. + + o Adding user preferences or device profile to the service request + to get personalized or adapted services. + + o Blocking or redirecting a service request due to a corporate + policy. + + An OPES processor may also modify a service request on behalf of the + data provider in several ways, such as: + + o Redirecting the request to a different server to reduce the server + work load. + + o Redirecting image requests to improve access time. + +2.1.2. Services *not* intending to modify requests + + An OPES processor may invoke useful service applications that do not + modify the user requests. Examples include: + + o Administrative functions for the data provider, such as service + monitoring or usage tracking for billing purposes. + + o Useful services for the data consumer, such as user profiling + (with the user's consent) for service adaptation later on. + +2.2. Services performed on responses + + An OPES service performed on HTTP responses may occur when a response + arrives at an OPES processor (point 3) or when it is about to leave + the OPES processor (point 4). In the case of a caching proxy, the + former service may be an encoding operation before the content is + stored in the cache, while the latter may be a decoding operation + before the content is returned to the data consumer. + + The services performed on responses can further be divided into two + cases: those that intend to modify responses and those that do not. + +2.2.1. Services intending to modify responses + + There are several reasons why responses from the data providers might + be modified before delivery to the data consumer: + + o Content adaptation: the data provider may not have all the device + + + +Barbir, et al. Informational [Page 4] + +RFC 3752 OPES Scenarios April 2004 + + + profiles and templates necessary to transcode the original content + into a format appropriate for mobile devices of limited screen + size and display capabilities. + + o Language translation: the data provider may not have all the + translation capabilities needed to deliver the same content in + multiple languages to various areas around the world. An OPES + processor may perform the language translation or it may invoke + different callout servers to perform different language + translation tasks. + +2.2.2. Services *not* intending to modify responses + + An OPES service may be performed on the responses without modifying + them. Examples include: + + o Logging/Monitoring: Each response may be examined and recorded for + monitoring or debugging purposes. + + o Accounting: An OPES processor may record the usage data (time and + space) of each service request for billing purposes. + +2.3. Services creating responses + + Services creating responses may include OPES services that + dynamically assemble web pages based on the context of the data + consumer application. + + Consider a content provider offering web pages that include a local + weather forecast based on the requestor's preferences. The OPES + service could analyze received requests, identify associated user + preferences, select appropriate templates, insert the corresponding + local weather forecasts, and would then deliver the content to the + requestor. Note that the OPES processor may perform the tasks with + or without direct access to the weather data. For example, the + service could use locally cached weather data or it could simply + embed a URL pointing to another server that holds the latest local + weather forecast information. + +3. OPES deployment scenarios + + OPES entities can be deployed over an overlay network that supports + the provisioning of data services in a distributed manner. Overlay + networks are an abstraction that creates a virtual network of + connected devices layered on an existing underlying IP networks in + order to perform application level services. + + The use of overlay networks creates virtual networks that via OPES + + + +Barbir, et al. Informational [Page 5] + +RFC 3752 OPES Scenarios April 2004 + + + entities enables the necessary network infrastructure to provide + better services for data consumer and provider applications. At the + application level, the resulting overlay networks are termed OPES + Services Networks. + + There are two parties that are interested in the services that are + offered by OPES entities, the delegate and the surrogate. Delegates + are authorized agents that act on behalf of data consumers. + Surrogates are authorized agents that act on behalf of data + providers. + + All parties that are involved in enforcing policies must communicate + the policies to the parties that are involved. These parties are + trusted to adhere to the communicated policies. + + In order to delegate fine-grained trust, the parties must convey + policy information by implicit contract, by a setup protocol, by a + dynamic negotiation protocol, or in-line with application data + headers. + +3.1. Surrogate Overlays + + A surrogate overlay is a specific type of OPES service network, which + is delegated the authority to provide data services on behalf of one + or more origin servers. Such services include, but are not limited + to, dynamic assembling of web pages, watermarking, and content + adaptation. + + The elements of surrogate overlays act on behalf of origin severs and + logically belong to the authoritative domain of the respective origin + servers. The scenario is depicted in Figure 2. + + + + + + + + + + + + + + + + + + + + +Barbir, et al. Informational [Page 6] + +RFC 3752 OPES Scenarios April 2004 + + + ********************************************* + * * + * +--------+ Authoritative * + * | Origin | Domain * + * | Server | * + * +--------+ +------------+ * + * | | OPES Admin | * + * | | Server | * + * | +------------+ * + * | / * + * | / * + * +--------------+ +-----------------+ * + * | OPES |----- | Remote Call-out | * + * | Processor | | Server | * + * +--------------+ +-----------------+ * + * | * + ********************************************* + | + | + | + +---------------------------+ + | Data consumer application | + +---------------------------+ + + Figure 2: Authoritative Domains for Surrogate Overlays + +3.2. Delegate Overlays + + A delegate overlay is a specific type of OPES service network, which + is delegated the authority to provide data services on behalf of one + or more data consumer applications. + + Delegate overlays provide services that would otherwise be performed + by the data consumer applications. Such services include, but are + not limited to, virus scanning and content filtering. + + The elements of delegate overlays logically belong to the + authoritative domain of the respective data consumer application. + The situation is illustrated in Figure 3. + + + + + + + + + + + + +Barbir, et al. Informational [Page 7] + +RFC 3752 OPES Scenarios April 2004 + + + +--------+ + | Origin | + | Server | + +--------+ + | + | + | + ********************************************* + * | * + * +--------------+ +-----------------+ * + * | OPES |----- | Remote Call-out | * + * | Processor | | Server | * + * +--------------+ +-----------------+ * + * | \ * + * | +------------+ * + * | | OPES Admin | * + * | | Server | * + * | +------------+ * + * +---------------------+ * + * | Data consumer Appl. | Authoritative * + * +---------------------+ Domain * + * * + ********************************************* + + Figure 3: Authoritative Domains for Delegate Overlays + +3.3. Enterprise environment + + Deployment of OPES services in an enterprise environment is unique in + several ways: + + o Both data providers and data consumers are in the same + administrative domain and trust domain. This implies that the + logical OPES administrator has the authority to enforce corporate + policies on all data providers, data consumers, and OPES entities. + + o In the case when a callout server outside the corporate firewall + is invoked for services (such as language translation) that cannot + be performed inside the corporation, care must be taken to + guarantee a secure communication channel between the callout + server and corporate OPES entities. The callout server must also + adhere to all corporate security policies for the services + authorized. + + + + + + + + +Barbir, et al. Informational [Page 8] + +RFC 3752 OPES Scenarios April 2004 + + +3.4. Callout Servers + + In some cases the deployment of OPES services can benefit from the + use of callout servers that could distribute the workload of OPES + processors or to contract specialized services from other OPES + providers. + + In general, operations such as virus scanning that operate on large + objects are better handled through the use of a dedicated callout + server that is better designed to perform the memory intensive task + than what an OPES processor could handle. + +3.5. Chaining of OPES data filters and callout servers + + OPES data processors can be "chained" in two dimensions: along the + content path or along the callout path. In the latter case, the + callout servers can themselves be organized in series for handling + requests. Any content that is touched by more than one data + processor or more than one callout server has been handled by a + "chain". + + NOTE: Chaining of callout servers is deferred from version 1 of the + Protocol. The discussion of chaining is included here for + completeness. + +3.5.1. Chaining along the content path + + An OPES provider may have assigned OPES services to a set of + processors arranged in series. All content might move through the + series, and if the content matches the rules for a processor, it is + subjected to the service. In this way, the content can be enhanced + by several services. This kind of chaining can be successful if the + services are relatively independent. For example, the content might + be assembled by a service early in the chain and then further + decorated by a later service. + +3.5.2. Chaining along the callout path + + Alternatively, an OPES data processor might act as a content-level + switch in a cluster of other data processors and callout servers. + + The first stage might develop a processing schedule for the content + and direct it to other OPES data processors and/or callout servers. + For example, OPES processor A might handle all services assembling + content, OPES processor B might handle all services involving URL + translation, and OPES processor C might handle all content security + services. The first processor would determine that processors A and + + + + +Barbir, et al. Informational [Page 9] + +RFC 3752 OPES Scenarios April 2004 + + + C were needed for a particular content object, and it would direct + the content to those processors. In turn, the processors might use + several callout servers to accomplish the task. + +4. Failure cases and service notification + + These are illustrative cases where information about OPES processing + can help endpoint users determine where and why content modifications + are being performed. + + o Content provider uses an OPES data processor to enhance content + based only on context local to the provider. The local context + might be time of day, local URL, or available advertising, for + example. The content provider might find OPES logging to be + sufficient for debugging any problems in this case. However, the + content provider might also try direct probing by issuing a + request for the content and examining headers related to tracing. + If unexpected parameters show up in the trace headers, the content + provider's administrator can use these to correct the OPES rules + or detect the presence of an unexpected OPES processor in the + content path. + + o Content provider uses an OPES data processor to enhance content + based on context related to the requestor. The requestor may + notice that his requests do not elicit the same response as + another requestor. He may, for example, get an error message. If + he believes there is a configuration error on the OPES data + processor, he will need to provide information to the + administrator of it. If the information includes "OPES service + access control, action: blocked", for example, he can inquire + about the circumstances that will allow him to be added to the + access control list. In another example, if he sees a picture + unrelated to the surrounding text, and if the tracing shows "OPES + service choose picture, action: insert 640x480 weather.gif", he + might complain that the OPES service does not properly recognize + his geographic location and inserts the wrong weather map. In any + case, if the information is forwarded to the content provider, the + problem may be fixed. + + o End user has OPES processor available as part of his network + access environment. The end user may have selected "translate + English to Spanish" as an OPES service. If he sees "OPES service + language translation, action: destination language not supported, + no action", then he may inquire of the OPES service provider about + what languages are supported by the package. If the end user + feels that the source language is not properly represented by the + + + + + +Barbir, et al. Informational [Page 10] + +RFC 3752 OPES Scenarios April 2004 + + + provider, resulting in inability for the service to operate, he + (or the language service provider) can contact the content + provider. + + o If the content provider gets complaints from users about the + translation service and feels that the problem is not in the + content but in the service, he may recommend that the service not + be applied to his pages. He can do that through content headers, + for example, with the notation "No OPES service #8D3298EB" or "No + OPES class language translation". + + o End user's ISP or enterprise uses OPES to control user access + based on user profiles. The end user can see that the OPES + services are being applied by his ISP, but he cannot control them. + If he feels that the transformations bowdlerize the content he can + complain to the provider organization. + + o The content provider or end user relies on a content distribution + network and OPES is used within that network. OPES may be + authorized by either the content provider, end user, or both. The + content provider may suspect that his access control rules are not + being applied properly, for example. He may ask for notification + on all accesses to his content through a log. This request and + the logfile are outside the OPES architecture; there are security + implications for the request, the response, and the resources used + by the logfile. + +5. Security Considerations + + The document presents usage scenarios and deployment cases. Issues + related to the overall security of OPES entities are given in [1]. + +6. Informative References + + [1] A. Barbir et al., "An Architecture for Open Pluggable Edge + Services (OPES)", Work in Progress, July 2002. + + [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy + Considerations for Open Pluggable Edge Services", RFC 3238, + January 2002. + + [3] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., + Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. + Waldbusser, "Terminology for Policy-Based Management", RFC 3198, + November 2001. + + + + + + +Barbir, et al. Informational [Page 11] + +RFC 3752 OPES Scenarios April 2004 + + + [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., + Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- + HTTP/1.1", RFC 2616, June 1999. + + [5] OPES Working Group, "OPES Service Authorization and Enforcement + Requirements", Work in Progress, May 2002. + + [6] Beck, A., et al., "Requirements for OPES Callout Protocols", + Work in Progress, July 2002. + +7. Acknowledgements + + The authors would like to thank the participants of the OPES WG for + their comments on this document. + +8. Authors' Addresses + + Abbie Barbir + Nortel Networks + 3500 Carling Avenue + Nepean, Ontario K2H 8E9 + Canada + + Phone: +1 613 763 5229 + EMail: abbieb@nortelnetworks.com + + + Eric W. Burger + Brooktrout Technology, Inc. + 18 Keewaydin Dr. + Salem, NH 03079 + + EMail: e.burger@ieee.org + + + Yih-Farn Robin Chen + AT&T Labs - Research + 180 Park Avenue + Florham Park, NJ 07932 + US + + Phone: +1 973 360 8653 + EMail: chen@research.att.com + + + + + + + + +Barbir, et al. Informational [Page 12] + +RFC 3752 OPES Scenarios April 2004 + + + Stephen McHenry + 305 Vineyard Town Center, #251 + Morgan Hill, CA 95037 + US + + Phone: +1 408 683 2700 + EMail: stephen@mchenry.net + + + Hilarie Orman + Purple Streak Development + + EMail: ho@alum.mit.edu + + + Reinaldo Penno + Nortel Networks + 600 Technology Park Drive + Billerica, MA 01803 + US + + EMail: rpenno@nortelnetworks.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barbir, et al. Informational [Page 13] + +RFC 3752 OPES Scenarios April 2004 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78 and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Barbir, et al. Informational [Page 14] + -- cgit v1.2.3