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