idnits 2.17.1 draft-ietf-opes-scenarios-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 50 has weird spacing: '...rformed to re...' == Line 100 has weird spacing: '...xamines vario...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 21, 2002) is 7952 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 506, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 510, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 515, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 519, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 522, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 3238 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3198 (ref. '3') ** Obsolete normative reference: RFC 2616 (ref. '4') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Barbir 3 Internet-Draft Nortel Networks 4 Expires: December 20, 2002 E. Burger 5 SnowShore Networks, Inc. 6 R. Chen 7 AT&T Labs 8 S. McHenry 9 CacheWare, Inc. 10 H. Orman 11 Purple Streak Development 12 R. Penno 13 Nortel Networks 14 June 21, 2002 16 OPES Use Cases and Deployment Scenarios 17 draft-ietf-opes-scenarios-00 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at http:// 35 www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 20, 2002. 42 Copyright Notice 44 Copyright (C) The Internet Society (2002). All Rights Reserved. 46 Abstract 48 This memo provides a discussion of use cases and deployment scenarios 49 for Open Pluggable Edge Services (OPES). The work examines services 50 that could be performed to requests and/or responses. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Types of OPES services . . . . . . . . . . . . . . . . . . . 4 56 2.1 Services performed on requests . . . . . . . . . . . . . . . 4 57 2.1.1 Services intending to modify requests . . . . . . . . . . . 4 58 2.1.2 Services *not* intending to modify requests . . . . . . . . 5 59 2.2 Services performed on responses . . . . . . . . . . . . . . 5 60 2.2.1 Services intending to modify responses . . . . . . . . . . . 6 61 2.2.2 Services *not* intending to modify responses . . . . . . . . 6 62 2.3 Services creating responses . . . . . . . . . . . . . . . . 6 63 3. OPES deployment scenarios . . . . . . . . . . . . . . . . . 7 64 3.1 Surrogate Overlays . . . . . . . . . . . . . . . . . . . . . 7 65 3.2 Delegate Overlays . . . . . . . . . . . . . . . . . . . . . 8 66 3.3 Enterprise environment . . . . . . . . . . . . . . . . . . . 9 67 3.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . 10 68 3.5 Chaining of OPES data filters and callout servers . . . . . 10 69 3.5.1 Chaining along the content path . . . . . . . . . . . . . . 10 70 3.5.2 Chaining along the callout path . . . . . . . . . . . . . . 10 71 4. Failure cases and service notification . . . . . . . . . . . 12 72 5. Security Considerations . . . . . . . . . . . . . . . . . . 14 73 References . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 75 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 76 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 78 1. Introduction 80 The Open Pluggable Edge Services (OPES) [1] architecture enables 81 cooperative application services (OPES services) between a data 82 provider, a data consumer, and zero or more OPES processors. The 83 application services under consideration analyze and possibly 84 transform application-level messages exchanged between the data 85 provider and the data consumer. The execution of such services is 86 governed by a set of filtering rules installed on the OPES processor. 88 The rules enforcement can trigger the execution of service 89 applications local to the OPES processor. Alternatively, the OPES 90 processor can distribute the responsibility of service execution by 91 communicating and collaborating with one or more remote callout [7] 92 servers. 94 The document presents examples of services in which Open Pluggable 95 Edge Services (OPES) would be useful. There are different types of 96 OPES services: services that modify requests, services that modify 97 responses, and a special case of the latter, services that create 98 responses. 100 The work also examines various deployment scenarios of OPES 101 services. The two main deployment scenarios, as described by the 102 OPES architecture [1], are surrogate overlays and delegate overlays. 103 Surrogate overlays act on behalf of data provider applications, while 104 delegate overlays act on behalf of data consumer applications. The 105 document also describes combined surrogate and delegate overlays, as 106 one might find within an enterprise deployment. 108 The document is organized as follows: Section 2 discusses the various 109 types of OPES services. Section 3 introduces OPES deployment 110 scenarios. Section 4 discusses failure cases and service 111 notification. Section 5 discusses security considerations. 113 2. Types of OPES services 115 OPES scenarios involve services that can be performed on requests for 116 data and/or responses. OPES services can be classified into three 117 categories: services performed on requests, services performed on 118 responses, and services creating responses. In Figure 1, the four 119 service activation points for an OPES processor are depicted. The 120 data dispatcher examines OPES rules, enforces policies, and invokes 121 service applications (if applicable) at each service activation 122 point. 124 --------------------------------------------------------------------- 126 +------------------------------------------------+ 127 | +-------------+-------------+ | 128 | | Service Application | | 129 | +---------------------------+ | 130 Responses | Data Dispatcher | Responses 131 <============4== +---------------------------+ <=3=========== 132 Requests | HTTP | Requests 133 =============1=> +---------------------------+ ==2==========> 134 | OPES Processor | 135 +------------------------------------------------+ 137 Figure 1: Service Activation Points 139 --------------------------------------------------------------------- 141 2.1 Services performed on requests 143 An OPES service performed on HTTP requests may occur when a request 144 arrives at an OPES processor (point 1) or when it is about to leave 145 the OPES processor (point 2). 147 The services performed on requests can further be divided into two 148 cases: those that intend to modify requests and those that do not. 150 2.1.1 Services intending to modify requests 152 An OPES processor may modify a service request on behalf of the data 153 consumer for various reasons, such as: 155 o Owner of a Web access device might need control over what kind of 156 Web content can be accessed with the device, parental control for 157 example. 159 o Organization may restrict or redirect access to certain web 160 services based on various criterias such as time of the day or the 161 employee access privileges. 163 o Hiding the data consumer's identity, user agent, or referrer. 165 o Adding user preferences or device profile to the service request 166 to get personalized or adapted services. 168 o Blocking or redirecting a service request due to a corporate 169 policy. 171 An OPES processor may also modify a service request on behalf of the 172 data provider in several ways, such as: 174 o Redirecting the request to a different server to reduce the server 175 work load. 177 o Redirecting image requests to improve access time. 179 2.1.2 Services *not* intending to modify requests 181 An OPES processor may invoke useful service applications that do not 182 modify the user requests. Examples include: 184 o Administrative functions for the data provider, such as service 185 monitoring or usage tracking for billing purposes. 187 o Useful services for the data consumer, such as user profiling 188 (with the user's consent) for service adaptation later on. 190 2.2 Services performed on responses 192 An OPES service performed on HTTP responses may occur when a response 193 arrives at an OPES processor (point 3) or when it is about to leave 194 the OPES processor (point 4). In the case of a caching proxy, the 195 former service may be an encoding operation before the content is 196 stored in the cache, while the latter may be a decoding operation 197 before the content is returned to the data consumer. 199 The services performed on responses can further be divided into two 200 cases: those that intend to modify responses and those that do not. 202 2.2.1 Services intending to modify responses 204 There are several reasons why responses from the data providers might 205 be modified before delivery to the data consumer: 207 o Content adaptation: the data provider may not have all the device 208 profiles and templates necessary to transcode the original content 209 into a format appropriate for mobile devices of limited screen 210 size and display capabilities. 212 o Language translation: the data provider may not have all the 213 translation capabilities needed to deliver the same content in 214 multiple languages to various areas around the world. An OPES 215 processor may perform the language translation or it may invoke 216 different callout servers to perform different language 217 translation tasks. 219 2.2.2 Services *not* intending to modify responses 221 An OPES service may be performed on the responses without modifying 222 them. Examples include: 224 o Logging/Monitoring: Each response may be examined and recorded for 225 monitoring or debugging purposes. 227 o Accounting: An OPES processor may record the usage data (time and 228 space) of each service request for billing purposes. 230 2.3 Services creating responses 232 Services creating responses may include OPES services that 233 dynamically assemble web pages based on the context of the data 234 consumer application. 236 Consider a content provider offering web pages that include a local 237 weather forecast based on the requestor's preferences. The OPES 238 service could analyze received requests, identify associated user 239 preferences, select appropriate templates, insert the corresponding 240 local weather forecasts, and would then deliver the content to the 241 requestor. Note that the OPES processor may perform the tasks with 242 or without direct access to the weather data. For example, the 243 service could use locally cached weather data or it could simply 244 embedd a URL pointing to another server that holds the latest local 245 weather forecast information. 247 3. OPES deployment scenarios 249 OPES entities can be deployed over an overlay network that supports 250 the provisioning of data services in a distributed manner. Overlay 251 networks are an abstraction that creates a virtual network of 252 connected devices layered on an existing underlying IP networks in 253 order to perform application level services. 255 The use of overlay networks creates virtual networks that via OPES 256 entities enables the necessary network infrastructure to provide 257 better services for data consumer and provider applications. At the 258 application level, the resulting overlay networks are termed OPES 259 Services Networks. 261 There are two parties that are interested in the services that are 262 offered by OPES entities, the delegate and the surrogate. Delegates 263 are authorized agents that act on behalf of data consumers. 264 Surrogates are authorized agents that act on behalf of data 265 providers. 267 All parties that are involved in enforcing policies must communicate 268 the policies to the parties that are involved. These parties are 269 trusted to adhere to the communicated policies. 271 In order to delegate fine-grained trust, the parties must convey 272 policy information by implicit contract, by a setup protocol, by a 273 dynamic negotiation protocol, or in-line with application data 274 headers. 276 3.1 Surrogate Overlays 278 A surrogate overlay is a specific type of OPES service network, which 279 is delegated the authority to provide data services on behalf of one 280 or more origin servers. Such services include, but are not limited 281 to, dynamic assembling of web pages, watermarking, and content 282 adaptation. 284 The elements of surrogate overlays act on behalf of origin severs and 285 logically belong to the authoritative domain of the respective origin 286 servers. The scenario is depicted in Figure 2. 288 --------------------------------------------------------------------- 290 ********************************************* 291 * * 292 * +--------+ Authoritative * 293 * | Origin | Domain * 294 * | Server | * 295 * +--------+ +------------+ * 296 * | | OPES Admin | * 297 * | | Server | * 298 * | +------------+ * 299 * | / * 300 * | / * 301 * +--------------+ +-----------------+ * 302 * | OPES |----- | Remote Call-out | * 303 * | Processor | | Server | * 304 * +--------------+ +-----------------+ * 305 * | * 306 ********************************************* 307 | 308 | 309 | 310 +---------------------------+ 311 | Data consumer application | 312 +---------------------------+ 314 Figure 2: Authoritative Domains for Surrogate Overlays 316 --------------------------------------------------------------------- 318 3.2 Delegate Overlays 320 A delegate overlay is a specific type of OPES service network, which 321 is delegated the authority to provide data services on behalf of one 322 or more data consumer applications. 324 Delegate overlays provide services that would otherwise be performed 325 by the data consumer applications. Such services include, but are 326 not limited to, virus scanning and content filtering. 328 The elements of delegate overlays logically belong to the 329 authoritative domain of the respective data consumer application. 330 The situation is illustrated in Figure 3. 332 --------------------------------------------------------------------- 334 +--------+ 335 | Origin | 336 | Server | 337 +--------+ 338 | 339 | 340 | 341 ********************************************* 342 * | * 343 * +--------------+ +-----------------+ * 344 * | OPES |----- | Remote Call-out | * 345 * | Processor | | Server | * 346 * +--------------+ +-----------------+ * 347 * | \ * 348 * | +------------+ * 349 * | | OPES Admin | * 350 * | | Server | * 351 * | +------------+ * 352 * +---------------------+ * 353 * | Data consumer Appl. | Authoritative * 354 * +---------------------+ Domain * 355 * * 356 ********************************************* 358 Figure 3: Authoritative Domains for Delegate Overlays 360 --------------------------------------------------------------------- 362 3.3 Enterprise environment 364 Deployment of OPES services in an enterprise environment is unique in 365 several ways: 367 o Both data providers and data consumers are in the same 368 administrative domain and trust domain. This implies that the 369 logical OPES administrator has the authority to enforce corporate 370 policies on all data providers, data consumers, and OPES entities. 372 o In the case when a callout server outside the corporate firewall 373 is invoked for services (such as language translation) that cannot 374 be performed inside the corporation, care must be taken to 375 guarantee a secure communication channel between the callout 376 server and corporate OPES entities. The callout server must also 377 adhere to all corporate security policies for the services 378 authorized. 380 3.4 Callout Servers 382 In some cases the deployment of OPES services can benefit from the 383 use of callout servers that could distribute the workload of OPES 384 processors or to contract specialized services from other OPES 385 providers. 387 In general, operations such as virus scanning that operate on large 388 objects are better handled through the use of a dedicated callout 389 server that is better designed to perform the memory intensive task 390 than what an OPES processor could handle. 392 3.5 Chaining of OPES data filters and callout servers 394 OPES data processors can be "chained" in two dimensions: along the 395 content path or along the callout path. In the latter case, the 396 callout servers can themselves be organized in series for handling 397 requests. Any content that is touched by more than one data 398 processor or more than one callout server has been handled by a 399 "chain". 401 3.5.1 Chaining along the content path 403 An OPES provider may have assigned OPES services to a set of 404 processors arranged in series. All content might move through the 405 series, and if the content matches the rules for a processor, it is 406 subjected to the service. In this way, the content can be enhanced 407 by several services. This kind of chaining can be successful if the 408 services are relatively independent. For example, the content might 409 be assembled by a service early in the chain and then further 410 decorated by a later service. 412 3.5.2 Chaining along the callout path 414 Alternatively, an OPES data processor might act as a content-level 415 switch in a cluster of other data processors and callout servers. 416 The first stage might develop a processing schedule for the content 417 and direct it to other OPES data processors and/or callout servers. 418 For example, OPES processor A might handle all services assembling 419 content, OPES processor B might handle all services involving URL 420 translation, and OPES processor C might handle all content security 421 services. The first processor would determine that processors A and 422 C were needed for a particular content object, and it would direct 423 the content to those processors. In turn, the processors might use 424 several callout servers to accomplish the task. 426 4. Failure cases and service notification 428 These are illustrative cases where information about OPES processing 429 can help endpoint users determine where and why content modifications 430 are being performed. 432 o Content provider uses an OPES data processor to enhance content 433 based only on context local to the provider. The local context 434 might be time of day, local URL, or available advertising, for 435 example. The content provider might find OPES logging to be 436 sufficient for debugging any problems in this case. However, the 437 content provider might also try direct probing by issuing a 438 request for the content and examining headers related to tracing. 439 If unexpected parameters show up in the trace headers, the content 440 provider's administrator can use these to correct the OPES rules 441 or detect the presence of an unexpected OPES processor in the 442 content path. 444 o Content provider uses an OPES data processor to enhance content 445 based on context related to the requestor. The requestor may 446 notice that his requests do not elicit the same response as 447 another requestor. He may, for example, get an error message. If 448 he believes there is a configuration error on the OPES data 449 processor, he will need to provide information to the 450 administrator of it. If the information includes "OPES service 451 access control, action: blocked", for example, he can inquire 452 about the circumstances that will allow him to be added to the 453 access control list. In another example, if he sees a picture 454 unrelated to the surrounding text, and if the tracing shows "OPES 455 service choose picture, action: insert 640x480 weather.gif", he 456 might complain that the OPES service does not properly recognize 457 his geographic location and inserts the wrong weather map. In any 458 case, if the information is forwarded to the content provider, the 459 problem may be fixed. 461 o End user has OPES processor available as part of his network 462 access environment. The end user may have selected "translate 463 English to Spanish" as an OPES service. If he sees "OPES service 464 language translation, action: destination language not supported, 465 no action", then he may inquire of the OPES service provider about 466 what languages are supported by the package. If the end user 467 feels that the source language is not properly represented by the 468 provider, resulting in inability for the service to operate, he 469 (or the language service provider) can contact the content 470 provider. 472 o If the content provider gets complaints from users of the 473 translation service and feels that the problem is not in the 474 content but in the content but in the service, he may recommend 475 that the service not be applied to his pages. He can do that 476 through content headers, for example, with the notation "No OPES 477 service #8D3298EB" or "No OPES class language translation". 479 o End user's ISP or enterprise uses OPES to control user access 480 based on user profiles. The end user can see that the OPES 481 services are being applied by his ISP, but he cannot control them. 482 If he feels that the transformations bowdlerize the content he can 483 complain to the provider organization. 485 o The content provider or end user relies on a content distribution 486 network and OPES is used within that network. OPES may be 487 authorized by either the content provider, end user, or both. The 488 content provider may suspect that his access control rules are not 489 being applied properly, for example. He may ask for notification 490 on all accesses to his content through a log. This request and 491 the logfile are outside the OPES architecture; there are security 492 implications for the request, the response, and the resources used 493 by the logfile. 495 5. Security Considerations 497 The document presents usage scenarios and deployment cases. Issues 498 related to the overall security of OPES entities are given in [1]. 500 References 502 [1] A. Barbir et. al, "An Architecture for Open Pluggable Edge 503 Services (OPES)", Internet-Draft: http://www.ietf.org/internet- 504 drafts/draft-ietf-opes-architecture-02.txt, June 2002. 506 [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy 507 Considerations for Open Pluggable Edge Services", RFC 3238, 508 January 2002. 510 [3] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 511 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. 512 Waldbusser, "Terminology for Policy-Based Management", RFC 3198, 513 November 2001. 515 [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 516 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 517 HTTP/1.1", RFC 2616, June 1999. 519 [5] OPES working group, "OPES Service Authorization and Enforcement 520 Requirements", Internet-Draft TBD, May 2002. 522 [6] OPES working group, "OPES Ruleset Schema", Internet-Draft TBD, 523 May 2002. 525 [7] A. Beck et al., "Requirements for OPES Callout Protocols", 526 Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf- 527 opes-protocol-reqs-00.txt, May 2002. 529 Authors' Addresses 531 Abbie Barbir 532 Nortel Networks 533 3500 Carling Avenue 534 Nepean, Ontario K2H 8E9 535 Canada 537 Phone: +1 613 763 5229 538 EMail: abbieb@nortelnetworks.com 539 Eric W. Burger 540 SnowShore Networks, Inc. 541 285 Billerica Rd 542 Chelmsford, MA 01820-4120 543 USA 545 Phone: 546 EMail: eburger@snowshore.com 548 Robin Chen 549 AT&T Labs 550 Room E219, 180 Park Avenue 551 Florham Park, NJ 07932 552 US 554 Phone: +1 973 360 8653 555 EMail: chen@research.att.com 557 Stephen McHenry 558 CacheWare, Inc. 559 Suite 150 560 655 Campbell Technology Parkway, Suite 150 561 Campbell, CA 95008 562 US 564 Phone: (408) 540-1270 565 EMail: stephen@cacheware.com 567 Hilarie Orman 568 Purple Streak Development 570 Phone: 571 EMail: ho@alum.mit.edu 573 Reinaldo Penno 574 Nortel Networks 575 4555 Great America Parkway 576 Santa Clara, CA 95054 577 US 579 EMail: rpenno@nortelnetworks.com 581 Appendix A. Acknowledgements 583 TBD 585 Full Copyright Statement 587 Copyright (C) The Internet Society (2002). All Rights Reserved. 589 This document and translations of it may be copied and furnished to 590 others, and derivative works that comment on or otherwise explain it 591 or assist in its implementation may be prepared, copied, published 592 and distributed, in whole or in part, without restriction of any 593 kind, provided that the above copyright notice and this paragraph are 594 included on all such copies and derivative works. However, this 595 document itself may not be modified in any way, such as by removing 596 the copyright notice or references to the Internet Society or other 597 Internet organizations, except as needed for the purpose of 598 developing Internet standards in which case the procedures for 599 copyrights defined in the Internet Standards process must be 600 followed, or as required to translate it into languages other than 601 English. 603 The limited permissions granted above are perpetual and will not be 604 revoked by the Internet Society or its successors or assigns. 606 This document and the information contained herein is provided on an 607 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 608 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 609 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 610 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 611 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 613 Acknowledgement 615 Funding for the RFC Editor function is currently provided by the 616 Internet Society.