idnits 2.17.1 draft-ietf-opes-iab-05.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.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 123: '... "OPES processors MUST be consented to...' RFC 2119 keyword, line 167: '...requires that "OPES processors MUST be...' RFC 2119 keyword, line 399: '...s. An OPES system MUST leave its trace...' RFC 2119 keyword, line 408: '... traces MUST include identification ...' RFC 2119 keyword, line 455: '... An OPES system MUST leave its trace [I-D.ietf-opes-end-comm]....' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (April 12, 2004) is 7319 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) == Outdated reference: A later version (-08) exists of draft-ietf-opes-end-comm-06 ** Downref: Normative reference to an Informational draft: draft-ietf-opes-end-comm (ref. 'I-D.ietf-opes-end-comm') ** Downref: Normative reference to an Informational draft: draft-ietf-opes-architecture (ref. 'I-D.ietf-opes-architecture') ** Downref: Normative reference to an Informational draft: draft-ietf-opes-scenarios (ref. 'I-D.ietf-opes-scenarios') ** Downref: Normative reference to an Informational RFC: RFC 3238 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-03) exists of draft-ietf-opes-http-01 == Outdated reference: A later version (-05) exists of draft-ietf-opes-ocp-core-03 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Pluggable Edge Services A. Barbir 3 Internet-Draft Nortel Networks 4 Expires: October 11, 2004 A. Rousskov 5 The Measurement Factory 6 April 12, 2004 8 OPES Treatment of IAB Considerations 9 draft-ietf-opes-iab-05 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 11, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 IETF Internet Architecture Board (IAB) expressed nine 40 architecture-level considerations for the Open Pluggable Edge 41 Services (OPES) framework. This document describes how OPES 42 addresses those considerations. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 5 49 4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 6 50 5. Notification Considerations . . . . . . . . . . . . . . . . . 8 51 5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8 52 5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 10 53 5.3 Consideration (3.1) 'Notification' . . . . . . . . . . . . . . 11 54 5.4 Consideration (3.2) 'Notification' . . . . . . . . . . . . . . 12 55 6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 13 56 7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 14 57 8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 15 58 9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 16 59 10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 17 60 11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 18 61 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 62 13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 20 63 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 64 Normative References . . . . . . . . . . . . . . . . . . . . . 24 65 Informative References . . . . . . . . . . . . . . . . . . . . 25 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 67 Intellectual Property and Copyright Statements . . . . . . . . 26 69 1. Introduction 71 The Open Pluggable Edge Services (OPES) architecture 72 [I-D.ietf-opes-architecture], enables cooperative application 73 services (OPES services) between a data provider, a data consumer, 74 and zero or more OPES processors. The application services under 75 consideration analyze and possibly transform application-level 76 messages exchanged between the data provider and the data consumer. 78 In the process of chartering OPES, the IAB made recommendations on 79 issues that OPES solutions should be required to address. These 80 recommendations were formulated in the form of a specific IAB 81 considerations document [RFC3238]. In that document, IAB emphasized 82 that its considerations did not recommend specific solutions and did 83 not mandate specific functional requirements. Addressing an IAB 84 consideration may involve showing appropriate protocol mechanisms or 85 demonstrating that the issue does not apply. Addressing a 86 consideration does not necessarily mean supporting technology implied 87 by the consideration wording. 89 The primary goal of this document is to show that all formal IAB 90 recommendations are addressed by OPES, to the extent that those 91 considerations can be addressed by an IETF working group. The 92 limitations of OPES working group to address certain aspects of IAB 93 considerations are also explicitly documented. 95 IAB considerations document [RFC3238] contains many informal 96 recommendations. For example, while the IAB informally requires OPES 97 architecture to "protect end-to-end data integrity by supporting 98 end-host detection and response to inappropriate behavior by OPES 99 intermediaries", the IAB has chosen to formalize these requirements 100 via a set of more specific recommendations, such as Notification 101 considerations addressed in Section 5.3 and Section 5.4 below. OPES 102 framework addresses informal IAB recommendations by addressing 103 corresponding formal considerations. 105 There are nine formal IAB considerations [RFC3238] that OPES has to 106 address. In the core of this document are the corresponding nine 107 "Consideration" sections. For each IAB consideration, its section 108 contains general discussion as well as references to specific OPES 109 mechanisms relevant to the consideration. 111 2. Terminology 113 This document does not introduce any new terminology but uses 114 terminology from other OPES documents it quotes. 116 3. Consideration (2.1) 'One-party consent' 118 "An OPES framework standardized in the IETF must require that the use 119 of any OPES service be explicitly authorized by one of the 120 application-layer end-hosts (that is, either the content provider or 121 the client)."[RFC3238] 123 OPES architecture requires that "OPES processors MUST be consented to 124 by either the data consumer or data provider application" 125 [I-D.ietf-opes-architecture]. While this requirement directly 126 satisfies IAB concern, no requirement alone can prevent consent-less 127 introduction of OPES processors. In other words, OPES framework 128 requires one-party consent but cannot guarantee it in the presence of 129 incompliant OPES entities. 131 In [I-D.ietf-opes-end-comm], the OPES architecture enables concerned 132 parties to detect unwanted OPES processors by examining OPES traces. 133 While the use of traces in OPES is mandatory, a tracing mechanism on 134 its own cannot detect processors that are in violation of OPES 135 specifications. Examples include OPES processors operating in 136 stealth mode. However, the OPES architecture allows the use of 137 content signature to verify the authenticity of performed 138 adaptations. Content signatures is a strong but expensive mechanism 139 that can detect any modifications of signed content provided that the 140 content provider is willing to sign the data and that the client is 141 willing to either check the signature or relay received content to 142 the content provider for signature verification. 144 OPES entities may copy or otherwise access content without modifying 145 it. Such access cannot be detected using content signatures. Thus, 146 "passive" OPES entities can operate on signed content without the 147 data consumer or provider consent. If content privacy is a concern, 148 then content encryption can be used. A passive processor is no 149 different from any intermediary operating outside of OPES framework. 150 No OPES mechanism (existing or foreseeable) can prevent non-modifying 151 access to content. 153 In summary, the one-party consent is satisfied by including the 154 corresponding requirement in the IAB architecture document. That 155 requirement alone cannot stop incompliant OPES entities to perform 156 consent-less adaptations, but OPES framework allows for various means 157 of detecting and/or preventing such adaptations. These means 158 typically introduce overheads and require some level of 159 producer-consumer cooperation. 161 4. Consideration (2.2) 'IP-layer communications' 163 "For an OPES framework standardized in the IETF, the OPES 164 intermediary must be explicitly addressed at the IP layer by the end 165 user."[RFC3238] 167 The OPES architecture requires that "OPES processors MUST be 168 addressable at the IP layer by the end user (data consumer 169 application)" [I-D.ietf-opes-architecture]. The IAB and the 170 architecture documents mention an important exception: addressing the 171 first OPES processor in a chain of processors is sufficient. That is, 172 a chain of OPES processors is viewed as a single OPES "system" at the 173 address of the first chain element. 175 The notion of a chain is not strictly defined by IAB. For the purpose 176 of addressing this consideration, a group of OPES processors working 177 on a given application transaction is considered. Such a group would 178 necessarily form a single processing chain, with a single "exit" OPES 179 processor (i.e., the processor that adapted the given message last). 180 The OPES architecture essentially requires that last OPES processor 181 to be explicitly addressable at the IP layer by the data consumer 182 application. The chain formation, including its exit point may depend 183 on an application message and other dynamic factors such as time of 184 the day or system load. 186 Furthermore, if OPES processing is an internal processing step at a 187 data consumer or a data provider application side, then the last OPES 188 processor may reside in a private address space and may not be 189 explicitly addressable from the outside. In such situations, the 190 processing side must designate an addressable point on the same 191 processing chain. That designated point may not be, strictly 192 speaking, an OPES processor, but it will suffice as such as far as 193 IAB considerations are concerned -- the data consumer application 194 will be able to address it explicitly at the IP layer and it will 195 represent the OPES processing chain to the outside world. 197 Designating an addressable processing point avoids the conflict 198 between narrow interpretation of the IAB consideration and real 199 system designs. It is irrational to expect a content provider to 200 provide access to internal hosts participating in content generation, 201 whether OPES processors are involved or not. Moreover, providing such 202 access would serve little practical purpose because internal OPES 203 processors are not likely to be able to answer any data consumer 204 queries, being completely out of content generation context. For 205 example, an OPES processor adding customer-specific information to 206 XML pages may not understand or be aware of any final HTML content 207 that the data consumer application receives and may not be able to 208 map end user request to any internal user identification. Since OPES 209 requires the end of the message processing chain to be addressable, 210 the conflict does not exist. OPES places no requirements on the 211 internal architecture of data producer systems while requiring the 212 entire OPES-related content production "system" to be addressable at 213 the IP layer. 215 Private Domain | Public Domain | Private Domain 216 | | 217 +--------------+ | +-------------+ +--------+ 218 | Data | | | OPES System | |Data | 219 | Consumer |<--- network -->| with public |<---->|Provider| 220 | Application | | | IP address | |App | 221 +--------------+ | +-------------+ +--------+ 222 | | 223 | | 225 Figure 1 227 5. Notification Considerations 229 This section discusses how OPES framework addresses IAB Notification 230 considerations 3.1 and 3.2. 232 5.1 Notification versus trace 234 Before specific considerations are discussed, the relationship 235 between IAB notifications and OPES tracing has to be explained. OPES 236 framework concentrates on tracing rather than notification. The OPES 237 Communications specification [I-D.ietf-opes-end-comm] defines "OPES 238 trace" as information about OPES adaptations that is embedded in an 239 application message. Thus, OPES trace follows the application message 240 it traces. The trace is for the recipient of the application message. 241 Traces are implemented as extensions of application protocols being 242 adapted and traced. 244 As opposed to an OPES trace, provider notification (as implied by 245 IAB) notifies the sender of the application message rather than the 246 recipient. Thus, notifications propagate in the opposite direction of 247 traces. Supporting notifications directly would require a new 248 protocol. Figure 2 illustrates the differences between a trace and 249 notification from a single application message point of view. 251 sender --[message A]--> OPES --[message A']--> recipient 252 ^ V [with trace] 253 | | 254 +-<-- [notification] ---+ 256 Figure 2 258 Since notifications cannot be piggy-backed to application messages, 259 they create new messages and may double the number of messages the 260 sender has to process. The number of messages that need to be proceed 261 is larger if several intermediaries on the message path generate 262 notifications. Associating notifications with application messages 263 may require duplicating application message information in 264 notifications and may require maintaining a sender state until 265 notification is received. These actions increase the performance 266 overhead of notifications. 268 The level of available details in notifications versus provider 269 interest in supporting notification is another concern. Experience 270 shows that content providers often require very detailed information 271 about user actions to be interested in notifications at all. For 272 example, Hit Metering protocol [RFC2227] has been designed to supply 273 content providers with proxy cache hit counts, in an effort to reduce 274 cache busting behavior which was caused by content providers desire 275 to get accurate site "access counts". However, the Hit Metering 276 protocol is currently not widely deployed because the protocol does 277 not supply content providers with information such as client IP 278 addresses, browser versions, or cookies. 280 Hit Metering experience is relevant because Hit Metering protocol was 281 designed to do for HTTP caching intermediaries what OPES 282 notifications are meant to do for OPES intermediaries. Performance 283 requirements call for state reduction via aggregation of 284 notifications while provider preferences call for state preservation 285 or duplication. Achieving the right balance when two sides belong to 286 different organizations and have different optimization priorities 287 may be impossible. 289 Thus, instead of explicitly supporting notifications at the protocol 290 level, OPES concentrates on tracing facilities. In essence, OPES 291 supports notifications indirectly, using tracing facilities. In other 292 words, the IAB choice of "Notification" label is interpreted as 293 "Notification assistance" (i.e. making notifications meaningful) and 294 is not interpreted as a "Notification protocol". 296 The above concerns call for making notification optional. The OPES 297 architecture allows for an efficient and meaningful notification 298 protocol to be implemented in certain OPES environments. For 299 example, an OPES callout server attached to a gateway or firewall may 300 scan outgoing traffic for signs of worm or virus activity and notify 301 a local Intrusion Detection System (IDS) of potentially compromised 302 hosts (e.g., servers or client PCs) inside the network. Such 303 notifications may use OPES tracing information to pinpoint the 304 infected host (which could be another OPES entity). In this example, 305 notifications are essentially sent back to the content producer (the 306 local network) and use OPES tracing to supply details. 308 Another environment where efficient and meaningful notification using 309 OPES tracing is possible are Content Delivery Networks (CDNs). A CDN 310 node may use multiple content adaptation services to customize 311 generic content supplied by the content producer (a web site). For 312 example, a callout service may insert advertisements for client-local 313 events. The CDN node itself may not understand specifics of the ad 314 insertion algorithm implemented at callout servers. However, the 315 node may use information in the OPES trace (e.g., coming from the 316 callout service) to notify the content producer. Such notifications 317 may be about the number of certain advertisements inserted (i.e., the 318 number of "impressions" delivered to the customer) or even the number 319 of ad "clicks" the customer made (e.g., if the node hosts content 320 linked from the ads). Callout services doing ad insertion may lack 321 details (e.g., a customer ID/address or a web server authentication 322 token) to contact the content producer directly in this case. Thus, 323 OPES trace produced by an OPES service becomes essential in enabling 324 meaningful notifications that the CDN node sends to the content 325 producer. 327 5.2 An example of an OPES trace for HTTP 329 The example below illustrates adaptations done to HTTP request at an 330 OPES processor operated by the client ISP. Both original (as sent by 331 an end user) and adapted (as received by the origin web server) 332 requests are shown. The primary adaptation is the modification of 333 HTTP "Accept" header. The secondary adaptation is the addition of an 334 OPES-System HTTP extension header [I-D.ietf-opes-http]. 336 GET /pub/WWW/ HTTP/1.1 337 Host: www.w3.org 338 Accept: text/plain 340 Figure 3 342 ... may be adapted by an ISP OPES system to become: 344 GET /pub/WWW/ HTTP/1.1 345 Host: www.w3.org 346 Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8 347 OPES-System: http://www.isp-example.com/opes/?client-hash=1234567 349 Figure 4 351 The example below illustrates adaptations done to HTTP response at an 352 OPES intermediary operated by a Content Distribution Network (CDN). 353 Both original (as sent by the origin web server) and adapted (as 354 received by the end user) responses are shown. The primary adaptation 355 is the conversion from HTML markup to plain text. The secondary 356 adaptation is the addition of an OPES-System HTTP extension header. 358 HTTP/1.1 200 OK 359 Content-Length: 12345 360 Content-Encoding: text/html 362

Available Documenta... 364 Figure 5 366 ... may be adapted by a CDN OPES system to become: 368 HTTP/1.1 200 OK 369 Content-Length: 2345 370 Content-Encoding: text/plain 371 OPES-System: http://www.cdn-example.com/opes/?site=7654&svc=h2t 373 AVAILABLE DOCUMENTA... 375 Figure 6 377 In the above examples, OPES-System header values contain URIs that 378 may point to OPES-specific documents such as description of the OPES 379 operator and its privacy policy. Those documents may be 380 parameterized to allow for customizations specific to the transaction 381 being traced (e.g., client or even transaction identifier may be used 382 to provide more information about performed adaptations). An OPES-Via 383 header may be used to provide a more detailed trace of specific OPES 384 entities within an OPES System that adapted the message. Traced OPES 385 URIs may be later used to request OPES bypass 386 [I-D.ietf-opes-end-comm]. 388 5.3 Consideration (3.1) 'Notification' 390 "The overall OPES framework needs to assist content providers in 391 detecting and responding to client-centric actions by OPES 392 intermediaries that are deemed inappropriate by the content 393 provider."[RFC3238] 395 OPES tracing mechanisms assist content providers in detecting 396 client-centric actions by OPES intermediaries. Specifically, a 397 compliant OPES intermediary or system notifies a content provider of 398 its presence by including its tracing information in the application 399 protocol requests. An OPES system MUST leave its trace 400 [I-D.ietf-opes-end-comm]. Detection assistance has its limitations. 401 Some OPES intermediaries may work exclusively on responses and may 402 not have a chance to trace the request. Moreover, some application 403 protocols may not have explicit requests (e.g., a content push 404 service). 406 OPES tracing mechanisms assist content providers in responding to 407 client-centric actions by OPES intermediaries. Specifically, OPES 408 traces MUST include identification of OPES systems and SHOULD include 409 a list of adaptation actions performed on provider's content. This 410 tracing information may be included in the application request. 411 Usually, however, this information will be included in the 412 application response, an adapted version of which does not reach the 413 content provider. If OPES end points cooperate, then notification can 414 be assisted with traces. Content providers that suspect or experience 415 difficulties can do any of the following: 417 o Check whether requests they receive pass through OPES 418 intermediaries. Presence of OPES tracing info will determine that. 419 This check is only possible for request/response protocols. For 420 other protocols (e.g., broadcast or push), the provider would have 421 to assume that OPES intermediaries are involved until proven 422 otherwise. 424 o If OPES intermediaries are suspected, request OPES traces from 425 potentially affected user(s). The trace will be a part of the 426 application message received by the user software. If involved 427 parties cooperate, the provider(s) may have access to all the 428 needed information. Certainly, lack of cooperation may hinder 429 access to tracing information. To encourage cooperation, data 430 providers might be able to deny service to uncooperative users. 432 o Some traces may indicate that more information is available by 433 accessing certain resources on the specified OPES intermediary or 434 elsewhere. Content providers may query for more information in 435 this case. 437 o If everything else fails, providers can enforce no-adaptation 438 policy using appropriate OPES bypass mechanisms and/or end-to-end 439 encryption mechanisms. 441 OPES detection and response assistance is limited to application 442 protocols with support for tracing extensions. For example, HTTP 443 [RFC2616] has such support while DNS over UDP does not. 445 5.4 Consideration (3.2) 'Notification' 447 "The overall OPES framework should assist end users in detecting the 448 behavior of OPES intermediaries, potentially allowing them to 449 identify imperfect or compromised intermediaries."[RFC3238] 451 OPES tracing mechanisms assist end users in detecting OPES 452 intermediaries. Specifically, a compliant OPES intermediary or system 453 notifies an end user of its presence by including its tracing 454 information in the application protocol messages sent to the client. 455 An OPES system MUST leave its trace [I-D.ietf-opes-end-comm]. 456 However, detection assistance has its limitations. Some OPES systems 457 may work exclusively on requests and may not have a chance to trace 458 the response. Moreover, some application protocols may not have 459 explicit responses (e.g., event logging service). 461 OPES detection assistance is limited to application protocols with 462 support for tracing extensions. For example, HTTP [RFC2616] has such 463 support while DNS over UDP does not. 465 6. Consideration (3.3) 'Non-blocking' 467 "If there exists a "non-OPES" version of content available from the 468 content provider, the OPES architecture must not prevent users from 469 retrieving this "non-OPES" version from the content 470 provider."[RFC3238] 472 "OPES entities MUST support a bypass feature" 473 [I-D.ietf-opes-end-comm]. If an application message includes bypass 474 instructions and an OPES intermediary is not configured to ignore 475 them, the matching OPES intermediary will not process the message. An 476 OPES intermediary may be configured to ignore bypass instructions 477 only if no non-OPES version of content is available. Bypass may 478 generate content errors since some OPES services may be essential but 479 may not be configured as such. 481 Bypass support has limitations similar to the two 482 notification-related considerations above. 484 7. Consideration (4.1) 'URI resolution' 486 "OPES documentation must be clear in describing these services as 487 being applied to the result of URI resolution, not as URI resolution 488 itself."[RFC3238] 490 "OPES Scenarios and Use Cases" specification 491 [I-D.ietf-opes-scenarios] documents content adaptations that are in 492 scope of the OPES framework. Scenarios include content adaptation of 493 requests and responses. These documented adaptations do not include 494 URI resolution. In some environments, it is technically possible to 495 use documented OPES mechanisms to resolve URIs (and other kinds of 496 identifiers or addresses). The OPES framework cannot effectively 497 prevent any specific kind of adaptation. 499 For example, a CDN node may substitute domain names in URLs with 500 CDN-chosen IP addresses, essentially performing a URI resolution on 501 behalf of the content producer (i.e., the web site owner). An OPES 502 callout service running on a user PC may rewrite all HTML-embedded 503 advertisement URLs to point to a user-specified local image, 504 essentially performing a URI redirection on behalf of the content 505 consumer (i.e., the end user). Such URI manipulations are outside of 506 the OPES framework scope, but cannot be effectively eliminated from 507 the real world. 509 8. Consideration (4.2) 'Reference validity' 511 "All proposed services must define their impact on inter- and 512 intra-document reference validity."[RFC3238] 514 The OPES framework does not propose adaptation services. However, 515 OPES tracing requirements include identification of OPES 516 intermediaries and services (for details, see "Notification" 517 consideration sections in this document). It is required that 518 provided identification can be used to locate information about the 519 OPES intermediaries, including the description of impact on reference 520 validity [I-D.ietf-opes-end-comm]. 522 9. Consideration (4.3) 'Addressing extensions' 524 "Any services that cannot be achieved while respecting the above two 525 considerations may be reviewed as potential requirements for Internet 526 application addressing architecture extensions, but must not be 527 undertaken as ad hoc fixes."[RFC3238] 529 OPES framework does not contain ad hoc fixes. This document in 530 combination with and other OPES documents should be sufficient to 531 inform service creators of IAB considerations. If a service does URI 532 resolution or silently affects document reference validity, the 533 authors are requested to review service impact on Internet 534 application addressing architecture and work within IETF on potential 535 extension requirements. Such actions would be outside of the current 536 OPES framework. 538 10. Consideration (5.1) 'Privacy' 540 "The overall OPES framework must provide for mechanisms for end users 541 to determine the privacy policies of OPES intermediaries."[RFC3238] 543 OPES tracing mechanisms allow end users to identify OPES 544 intermediaries (for details, see "Notification" consideration 545 sections in this document). It is required that provided 546 identification can be used to locate information about the OPES 547 intermediaries, including their privacy policies. 549 The term "privacy policy" is not defined in this context (by IAB or 550 OPES working group). OPES tracing mechanisms allow end users and 551 content providers to identify an OPES system and/or intermediaries. 552 It is believed that once an OPES system is identified, it would be 553 possible to locate relevant information about that system, including 554 information relevant to requesters perception of privacy policy or 555 reference validity. 557 11. Consideration 'Encryption' 559 "If OPES is chartered, the OPES working group will also have to 560 explicitly decide and document whether the OPES architecture must be 561 compatible with the use of end-to-end encryption by one or more ends 562 of an OPES-involved session. If OPES was compatible with end-to-end 563 encryption, this would effectively ensure that OPES boxes would be 564 restricted to ones that are known, trusted, explicitly addressed at 565 the IP layer, and authorized (by the provision of decryption keys) by 566 at least one of the ends."[RFC3238] 568 The above quoted requirement was not explicitly listed as on of the 569 IAB considerations, but still needs to be addressed. The context of 570 the quote implies that the phrase "end-to-end encryption" refers to 571 encryption along all links of the end-to-end path, with the OPES 572 intermediaries as encrypting/decrypting participants or hops (e.g., 573 encryption between the provider and the OPES intermediaries, and 574 between the OPES intermediaries and the client). 576 Since OPES processors are regular hops on the application protocol 577 path, OPES architecture allows for such encryption, provided the 578 application protocol being adapted supports it. Hop-by-hop encryption 579 would do little good for the overall application message path 580 protection if callout services have to receive unencrypted content. 581 To allow for complete link encryption coverage, OPES callout protocol 582 (OCP) supports encryption of OCP connections between an OPES 583 processor and a callout server via optional (negotiated) transport 584 encryption mechanisms [I-D.ietf-opes-ocp-core]. 586 For example, TLS encryption [RFC2817] can be used among HTTP hops 587 (some of which could be OPES processors) and between each OPES 588 processor and a callout server. 590 12. Security Considerations 592 This document does not define any mechanisms that may be subject to 593 security considerations. This document scope is to address specific 594 IAB considerations. Security of OPES mechanisms are discussed in 595 Security Considerations sections of the corresponding OPES framework 596 documents. 598 For example, OPES tracing mechanisms assist content providers and 599 consumers in protecting content integrity and confidentiality by 600 requiring OPES intermediaries to disclose their presence. Security of 601 the tracing mechanism is discussed in the Security Considerations 602 section of [I-D.ietf-opes-end-comm]. 604 13. Compliance 606 This document may be perceived as a proof of OPES compliance with IAB 607 implied recommendations. However, this document does not introduce 608 any compliance subjects. Compliance of OPES implementations is 609 defined in other OPES documents discussed above. 611 Appendix A. Change Log 613 RFC Editor Note: This section is to be removed during the final 614 publication of the document. 616 Internal WG revision control ID: $Id: iab-cons.xml,v 1.36 2004/04/12 617 16:06:52 rousskov Exp $ 619 2004/04/08 621 * Replaced "Cable Company ISP" Notification example with two new 622 examples to address IESG uncertainty about the meaning of the 623 old convoluted example. 625 * Polished text addressing "One-party consent" concern to better 626 show why the concern is addressed. It is not clear whether the 627 changes will address IESG review comment that "the WG does not 628 seem to get it" [because?] the text does not "name situations 629 where one-party consent does make sense". It is currently not 630 clear how naming such situations can address IAB concern, and 631 why naming such situations is in this document scope. 633 * Polished text discussing URI resolution consideration to talk 634 more specifically about the resolution of URIs rather than 635 (more general) adaptation of URIs and added examples. This 636 change is meant to address IESG concern that URI resolution is 637 not addressed or the corresponding description is confusing. 639 * Clarified in the Introduction that the purpose of this document 640 is to address nine formal IAB considerations, and that we hope 641 that addressing formal consideration is sufficient to address 642 any informal ones that are scattered through the IAB 643 Considerations document. This is meant to address IESG concern 644 that some [informal] words from the IAB Consideration document 645 do not explicitly appear in this document. 647 * Be more specific about where security of OPES mechanisms is 648 discussed. Added an example of where security of OPES tracing 649 mechanisms is discussed. This document is about addressing 650 specific IAB considerations and is not a map/index to OPES 651 mechanisms or their security. However, polished text and 652 example may provide the reader with more direct clues on where 653 to find security-related information that goes beyond the scope 654 of this document. 656 2003/11/18 658 * Added an example where an efficient and meaningful notification 659 protocol can be implemented in OPES. 661 * Assume Communications draft will contain wording about 662 documenting impact on reference validity. 664 * Use OPES-System HTTP header for examples and mention OPES-Via. 665 We still need to get HTTP Adaptations draft in sync with this 666 change, but the text now assumes that has been done. 668 2003/10/24 670 * Addressed hop-by-hop encryption concerns mentioned in the IAB 671 draft. 673 * Polished IP addressing figure. 675 * Removed resolved XXXs. 677 2003/10/01 679 * Polishing (Abbie Barbir). 681 2003/09/23 683 * Added a reference to Optional Notification section of the 684 ietf-opes-end-comm draft. 686 * Fixed "Consideration (3.3) Non-blocking" section position. 688 head-sid15 690 * Added a figure showing a chain of internal OPES intermediaries 691 behind a public IP address. Needs more work. More cases? 693 head-sid14 695 * Rewrote the Introduction to the IP addressing consideration. 696 Do NOT explain how IAB considerations, if interpreted literary, 697 do not satisfy important real-world constraints. Instead, use 698 the "chain of OPES intermediaries" exception introduced by IAB 699 itself to show that OPES architecture addresses IAB concerns as 700 long as the "chain" is defined/formed for a given application 701 message rather than being a statically configured application 702 routing table of sorts. IAB had to add the "chain" exception to 703 cover one of the most obvious real-world usage scenario. We use 704 the very same exception to cover all usage scenarios we care 705 about. 707 * Polished text explaining the differences between tracing and 708 notification mechanisms. 710 * Added examples of OPES/HTTP traces. 712 * Be careful not to imply that all OPES intermediaries must obey 713 bypass instructions. Bypass should be ignored when no non-OPES 714 version of the content exists. Ideally, this may need to be 715 polished further -- if there is no non-OPES version of the 716 content, most IAB considerations probably do not apply because 717 there is really no adaptation, only creation of content (and we 718 should not restrict content creation). 720 * Added references to OPES "Communications" draft 721 [I-D.ietf-opes-end-comm]. 723 head-sid9 725 * Polished to meet new xml2rfc strict requirements. 727 head-sid8 729 * Added unpolished meat for all nine considerations. 731 * Added Abbie Barbir as an author. 733 head-sid7 735 * Initial revision 737 Normative References 739 [I-D.ietf-opes-end-comm] 740 Barbir, A., "OPES entities and end points communication", 741 draft-ietf-opes-end-comm-06 (work in progress), December 742 2003. 744 [I-D.ietf-opes-architecture] 745 Barbir, A., "An Architecture for Open Pluggable Edge 746 Services (OPES)", draft-ietf-opes-architecture-04 (work in 747 progress), December 2002. 749 [I-D.ietf-opes-scenarios] 750 Barbir, A., "OPES Use Cases and Deployment Scenarios", 751 draft-ietf-opes-scenarios-01 (work in progress), August 752 2002. 754 [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy 755 Considerations for Open Pluggable Edge Services", RFC 756 3238, January 2002. 758 Informative References 760 [RFC2227] Mogul, J. and P. Leach, "Simple Hit-Metering and 761 Usage-Limiting for HTTP", RFC 2227, October 1997. 763 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 764 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 765 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 767 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/ 768 1.1", RFC 2817, May 2000. 770 [I-D.ietf-opes-http] 771 Rousskov, A. and M. Stecher, "HTTP adaptation with OPES", 772 draft-ietf-opes-http-01 (work in progress), October 2003. 774 [I-D.ietf-opes-ocp-core] 775 Rousskov, A., "OPES Callout Protocol Core", 776 draft-ietf-opes-ocp-core-03 (work in progress), November 777 2003. 779 Authors' Addresses 781 Abbie Barbir 782 Nortel Networks 783 3500 Carling Avenue 784 Nepean, Ontario 785 CA 787 Phone: +1 613 763 5229 788 EMail: abbieb@nortelnetworks.com 790 Alex Rousskov 791 The Measurement Factory 793 EMail: rousskov@measurement-factory.com 794 URI: http://www.measurement-factory.com/ 796 Intellectual Property Statement 798 The IETF takes no position regarding the validity or scope of any 799 intellectual property or other rights that might be claimed to 800 pertain to the implementation or use of the technology described in 801 this document or the extent to which any license under such rights 802 might or might not be available; neither does it represent that it 803 has made any effort to identify any such rights. Information on the 804 IETF's procedures with respect to rights in standards-track and 805 standards-related documentation can be found in BCP-11. Copies of 806 claims of rights made available for publication and any assurances of 807 licenses to be made available, or the result of an attempt made to 808 obtain a general license or permission for the use of such 809 proprietary rights by implementors or users of this specification can 810 be obtained from the IETF Secretariat. 812 The IETF invites any interested party to bring to its attention any 813 copyrights, patents or patent applications, or other proprietary 814 rights which may cover technology that may be required to practice 815 this standard. Please address the information to the IETF Executive 816 Director. 818 Full Copyright Statement 820 Copyright (C) The Internet Society (2004). All Rights Reserved. 822 This document and translations of it may be copied and furnished to 823 others, and derivative works that comment on or otherwise explain it 824 or assist in its implementation may be prepared, copied, published 825 and distributed, in whole or in part, without restriction of any 826 kind, provided that the above copyright notice and this paragraph are 827 included on all such copies and derivative works. However, this 828 document itself may not be modified in any way, such as by removing 829 the copyright notice or references to the Internet Society or other 830 Internet organizations, except as needed for the purpose of 831 developing Internet standards in which case the procedures for 832 copyrights defined in the Internet Standards process must be 833 followed, or as required to translate it into languages other than 834 English. 836 The limited permissions granted above are perpetual and will not be 837 revoked by the Internet Society or its successors or assignees. 839 This document and the information contained herein is provided on an 840 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 841 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 842 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 843 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 844 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 846 Acknowledgment 848 Funding for the RFC Editor function is currently provided by the 849 Internet Society.