idnits 2.17.1 draft-ietf-opes-iab-03.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 113: '... "OPES processors MUST be consented to...' RFC 2119 keyword, line 147: '...requires that "OPES processors MUST be...' RFC 2119 keyword, line 353: '...s. An OPES system MUST leave its trace...' RFC 2119 keyword, line 362: '... traces MUST include identification ...' RFC 2119 keyword, line 409: '... 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 (October 27, 2003) is 7480 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-04 ** 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-00 == Outdated reference: A later version (-05) exists of draft-ietf-opes-ocp-core-01 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: April 26, 2004 A. Rousskov 5 The Measurement Factory 6 October 27, 2003 8 OPES Treatment of IAB Considerations 9 draft-ietf-opes-iab-03 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 April 26, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). 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 . . . . . . . . . . . . . 9 53 5.3 Consideration (3.1) 'Notification' . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 23 65 Informative References . . . . . . . . . . . . . . . . . . . . 24 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 67 Intellectual Property and Copyright Statements . . . . . . . . 25 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 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 There are nine IAB considerations [RFC3238] that OPES has to address. 96 In the core of this document are the corresponding nine 97 "Consideration" sections. For each IAB consideration, its section 98 contains general discussion as well as references to specific OPES 99 mechanisms relevant to the consideration. 101 2. Terminology 103 This document does not introduce any new terminology but uses 104 terminology from other OPES documents it quotes. 106 3. Consideration (2.1) 'One-party consent' 108 "An OPES framework standardized in the IETF must require that the use 109 of any OPES service be explicitly authorized by one of the 110 application-layer end-hosts (that is, either the content provider or 111 the client)."[RFC3238] 113 OPES architecture requires that "OPES processors MUST be consented to 114 by either the data consumer or data provider application" 115 [I-D.ietf-opes-architecture]. This requirement alone cannot prevent 116 consent-less introduction of OPES processors. In 117 [I-D.ietf-opes-end-comm], the OPES architecture enables concerned 118 parties to detect unwanted OPES processors by examining OPES traces. 119 The use of traces in OPES is mandatory. 121 A tracing mechanism on its own cannot detect processors that are in 122 violation of OPES specifications. Examples include OPES processors 123 operating in stealth mode. However, the OPES architecture allows the 124 use of content signature to verify the authenticity of performed 125 adaptations. Content signatures is a strong but expensive mechanism 126 that can detect any modifications of signed content provided that the 127 content provider is willing to sign the data and that the client is 128 willing to either check the signature or relay received content to 129 the content provider for signature verification. 131 OPES adaptations may include copying and other forms of non-modifying 132 access to content. These kinds of adaptations cannot be detected by 133 the above mentioned mechanisms. Thus, "passive" OPES processors can 134 operate on the content without the data consumer or provider consent. 135 If presence of such processors is a concern, then content encryption 136 can be used. A passive processor is no different from a proxy or an 137 intermediary operating outside of OPES framework. No OPES mechanism 138 (existing or foreseeable) can prevent non-modifying access to 139 content. 141 4. Consideration (2.2) 'IP-layer communications' 143 "For an OPES framework standardized in the IETF, the OPES 144 intermediary must be explicitly addressed at the IP layer by the end 145 user."[RFC3238] 147 The OPES architecture requires that "OPES processors MUST be 148 addressable at the IP layer by the end user (data consumer 149 application)" [I-D.ietf-opes-architecture]. The IAB and the 150 architecture documents mention an important exception: addressing the 151 first OPES processor in a chain of processors is sufficient. That is, 152 a chain of OPES processors is viewed as a single OPES "system" at the 153 address of the first chain element. 155 The notion of a chain is not strictly defined by IAB. For the purpose 156 of addressing this consideration, a group of OPES processors working 157 on a given application transaction is considered. Such a group would 158 necessarily form a single processing chain, with a single "exit" OPES 159 processor (i.e., the processor that adapted the given message last). 160 The OPES architecture essentially requires that last OPES processor 161 to be explicitly addressable at the IP layer by the data consumer 162 application. The chain formation, including its exit point may depend 163 on an application message and other dynamic factors such as time of 164 the day or system load. 166 Furthermore, if OPES processing is an internal processing step at a 167 data consumer or a data provider application side, then the last OPES 168 processor may reside in a private address space and may not be 169 explicitly addressable from the outside. In such situations, the 170 processing side must designate an addressable point on the same 171 processing chain. That designated point may not be, strictly 172 speaking, an OPES processor, but it will suffice as such as far as 173 IAB considerations are concerned -- the data consumer application 174 will be able to address it explicitly at the IP layer and it will 175 represent the OPES processing chain to the outside world. 177 Designating an addressable processing point avoids the conflict 178 between narrow interpretation of the IAB consideration and real 179 system designs. It is irrational to expect a content provider to 180 provide access to internal hosts participating in content generation, 181 whether OPES processors are involved or not. Moreover, providing such 182 access would serve little practical purpose because internal OPES 183 processors are not likely to be able to answer any data consumer 184 queries, being completely out of content generation context. For 185 example, an OPES processor adding customer-specific information to 186 XML pages may not understand or be aware of any final HTML content 187 that the data consumer application receives and may not be able to 188 map end user request to any internal user identification. Since OPES 189 requires the end of the message processing chain to be addressable, 190 the conflict does not exist. OPES places no requirements on the 191 internal architecture of data producer systems while requiring the 192 entire OPES-related content production "system" to be addressable at 193 the IP layer. 195 Private Domain | Public Domain | Private Domain 196 | | 197 +--------------+ | +-------------+ +--------+ 198 | Data | | | OPES System | |Data | 199 | Consumer |<--- network -->| with public |<---->|Provider| 200 | Application | | | IP address | |App | 201 +--------------+ | +-------------+ +--------+ 202 | | 203 | | 205 Figure 1 207 5. Notification Considerations 209 This section discusses how OPES framework addresses IAB Notification 210 considerations 3.1 and 3.2. 212 5.1 Notification versus trace 214 Before specific considerations are discussed, the relationship 215 between IAB notifications and OPES tracing has to be explained. OPES 216 framework concentrates on tracing rather than notification. The OPES 217 Communications specification [I-D.ietf-opes-end-comm] defines "OPES 218 trace" as information about OPES adaptations that is embedded in an 219 application message. Thus, OPES trace follows the application message 220 it traces. The trace is for the recipient of the application message. 221 Traces are implemented as extensions of application protocols being 222 adapted and traced. 224 As opposed to an OPES trace, provider notification (as implied by 225 IAB) notifies the sender of the application message rather than the 226 recipient. Thus, notifications propagate in the opposite direction of 227 traces. Supporting notifications directly would require a new 228 protocol. Figure 2 illustrates the differences between a trace and 229 notification from a single application message point of view. 230 sender --[message A]--> OPES --[message A']--> recipient 231 ^ V [with trace] 232 | | 233 +-<-- [notification] ---+ 235 Figure 2 237 Since notifications cannot be piggy-backed to application messages, 238 they create new messages and may double the number of messages the 239 sender has to process. The number of messages that need to be proceed 240 is larger if several intermediaries on the message path generate 241 notifications). Associating notifications with application messages 242 may require duplicating application message information in 243 notifications and may require maintaining a sender state until 244 notification is received. These actions increase the performance 245 overhead of notifications. 247 The level of available details in notifications versus provider 248 interest in supporting notification is another concern. Experience 249 shows that content providers often require very detailed information 250 about user actions to be interested in notifications at all. For 251 example, Hit Metering protocol [RFC2227] has been designed to supply 252 content providers with proxy cache hit counts, in an effort to reduce 253 cache busting behavior which was caused by content providers desire 254 to get accurate site "access counts". However, the Hit Metering 255 protocol is currently not widely deployed because the protocol does 256 not supply content providers with information such as client IP 257 addresses, browser versions, or cookies. 259 Hit Metering experience is relevant because Hit Metering protocol was 260 designed to do for HTTP caching intermediaries what OPES 261 notifications are meant to do for OPES intermediaries. Performance 262 requirements call for state reduction via aggregation of 263 notifications while provider preferences call for state preservation 264 or duplication. Achieving the right balance when two sides belong to 265 different organizations and have different optimization priorities 266 may be impossible. 268 Thus, instead of explicitly supporting notifications at the protocol 269 level, OPES concentrates on tracing facilities. In essence, OPES 270 supports notifications indirectly, using tracing facilities. In other 271 words, the IAB choice of "Notification" label is interpreted as 272 "Notification assistance" (i.e. making notifications meaningful) and 273 is not interpreted as a "Notification protocol". 275 The above concerns call for making notification optional. The OPES 276 architecture allows for an efficient and meaningful notification 277 protocol to be implemented in certain OPES environments. For 278 specific examples, see the "Optional Notification" section in 279 [I-D.ietf-opes-end-comm]. 281 5.2 An example of an OPES trace for HTTP 283 The example below illustrates adaptations done to HTTP request at an 284 OPES processor operated by the client ISP. Both original (as sent by 285 an end user) and adapted (as received by the origin web server) 286 requests are shown. The primary adaptation is the modification of 287 HTTP "Accept" header. The secondary adaptation is the addition of an 288 "OPES-Via" HTTP extension header [I-D.ietf-opes-http] (XXX: but it is 289 not OPES-Via, it is OPES-System for now; OPES-Via is probably better 290 for a few reasons though). 292 GET /pub/WWW/ HTTP/1.1 293 Host: www.w3.org 294 Accept: text/plain 296 Figure 3 298 ... may be adapted by an ISP OPES system to become: 300 GET /pub/WWW/ HTTP/1.1 301 Host: www.w3.org 302 Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8 303 OPES-Via: http://www.isp-example.com/opes/?client-hash=1234567 305 Figure 4 307 The example below illustrates adaptations done to HTTP response at an 308 OPES intermediary operated by a Content Distribution Network (CDN). 309 Both original (as sent by the origin web server) and adapted (as 310 received by the end user) responses are shown. The primary adaptation 311 is the conversion from HTML markup to plain text. The secondary 312 adaptation is the addition of an "OPES-Via" HTTP extension header. 314 HTTP/1.1 200 OK 315 Content-Length: 12345 316 Content-Encoding: text/html 318

Available Documenta... 320 Figure 5 322 ... may be adapted by a CDN OPES system to become: 324 HTTP/1.1 200 OK 325 Content-Length: 2345 326 Content-Encoding: text/plain 327 OPES-Via: http://www.cdn-example.com/opes/?site=7654321&service=h2t 329 AVAILABLE DOCUMENTA... 331 Figure 6 333 In the above examples, "OPES-Via" header values contain URLs that may 334 point to OPES-specific documents such as description of the OPES 335 operator and its privacy policy. Those documents may be 336 parameterized to allow for customizations specific to the transaction 337 being traced (e.g., client or even transaction identifier may be used 338 to provide more information about performed adaptations). Traced OPES 339 URLs may be later used to request OPES bypass 340 [I-D.ietf-opes-end-comm]. 342 5.3 Consideration (3.1) 'Notification' 344 "The overall OPES framework needs to assist content providers in 345 detecting and responding to client-centric actions by OPES 346 intermediaries that are deemed inappropriate by the content 347 provider."[RFC3238] 349 OPES tracing mechanisms assist content providers in detecting 350 client-centric actions by OPES intermediaries. Specifically, a 351 compliant OPES intermediary or system notifies a content provider of 352 its presence by including its tracing information in the application 353 protocol requests. An OPES system MUST leave its trace 354 [I-D.ietf-opes-end-comm]. Detection assistance has its limitations. 355 Some OPES intermediaries may work exclusively on responses and may 356 not have a chance to trace the request. Moreover, some application 357 protocols may not have explicit requests (e.g., a content push 358 service). 360 OPES tracing mechanisms assist content providers in responding to 361 client-centric actions by OPES intermediaries. Specifically, OPES 362 traces MUST include identification of OPES systems and SHOULD include 363 a list of adaptation actions performed on provider's content. This 364 tracing information may be included in the application request. 365 Usually, however, this information will be included in the 366 application response, an adapted version of which does not reach the 367 content provider. If OPES end points cooperate, then notification can 368 be assisted with traces. Content providers that suspect or experience 369 difficulties can do any of the following: 371 o Check whether requests they receive pass through OPES 372 intermediaries. Presence of OPES tracing info will determine that. 373 This check is only possible for request/response protocols. For 374 other protocols (e.g., broadcast or push), the provider would have 375 to assume that OPES intermediaries are involved until proven 376 otherwise. 378 o If OPES intermediaries are suspected, request OPES traces from 379 potentially affected user(s). The trace will be a part of the 380 application message received by the user software. If involved 381 parties cooperate, the provider(s) may have access to all the 382 needed information. Certainly, lack of cooperation may hinder 383 access to tracing information. To encourage cooperation, data 384 providers might be able to deny service to uncooperative users. 386 o Some traces may indicate that more information is available by 387 accessing certain resources on the specified OPES intermediary or 388 elsewhere. Content providers may query for more information in 389 this case. 391 o If everything else fails, providers can enforce no-adaptation 392 policy using appropriate OPES bypass mechanisms and/or end-to-end 393 encryption mechanisms. 395 OPES detection and response assistance is limited to application 396 protocols with support for tracing extensions. For example, HTTP 397 [RFC2616] has such support while DNS over UDP does not. 399 5.4 Consideration (3.2) 'Notification' 401 "The overall OPES framework should assist end users in detecting the 402 behavior of OPES intermediaries, potentially allowing them to 403 identify imperfect or compromised intermediaries."[RFC3238] 405 OPES tracing mechanisms assist end users in detecting OPES 406 intermediaries. Specifically, a compliant OPES intermediary or system 407 notifies an end user of its presence by including its tracing 408 information in the application protocol messages sent to the client. 409 An OPES system MUST leave its trace [I-D.ietf-opes-end-comm]. 410 However, detection assistance has its limitations. Some OPES systems 411 may work exclusively on requests and may not have a chance to trace 412 the response. Moreover, some application protocols may not have 413 explicit responses (e.g., event logging service). 415 OPES detection assistance is limited to application protocols with 416 support for tracing extensions. For example, HTTP [RFC2616] has such 417 support while DNS over UDP does not. 419 6. Consideration (3.3) 'Non-blocking' 421 "If there exists a "non-OPES" version of content available from the 422 content provider, the OPES architecture must not prevent users from 423 retrieving this "non-OPES" version from the content 424 provider."[RFC3238] 426 "OPES entities MUST support a bypass feature" 427 [I-D.ietf-opes-end-comm]. If an application message includes bypass 428 instructions and an OPES intermediary is not configured to ignore 429 them, the matching OPES intermediary will not process the message. An 430 OPES intermediary may be configured to ignore bypass instructions 431 only if no non-OPES version of content is available. Bypass may 432 generate content errors since some OPES services may be essential but 433 may not be configured as such. 435 Bypass support has limitations similar to the two 436 notification-related considerations above. 438 7. Consideration (4.1) 'URI resolution' 440 "OPES documentation must be clear in describing these services as 441 being applied to the result of URI resolution, not as URI resolution 442 itself."[RFC3238] 444 "OPES Scenarios and Use Cases" specification 445 [I-D.ietf-opes-scenarios] documents content adaptations that are in 446 scope of the OPES framework. Scenarios include adaptations of 447 requests and responses. These adaptations do not include URI 448 resolution adaptations. In some environments, it is technically 449 possible to adapt URIs (and other kinds of identifiers or addresses) 450 using documented OPES mechanisms. The OPES framework cannot 451 effectively prohibit any specific adaptations. 453 8. Consideration (4.2) 'Reference validity' 455 "All proposed services must define their impact on inter- and 456 intra-document reference validity."[RFC3238] 458 The OPES framework does not propose adaptation services. However, 459 OPES tracing requirements include identification of OPES 460 intermediaries and services (for details, see "Notification" 461 consideration sections in this document). It is required that 462 provided identification can be used to locate information about the 463 OPES intermediaries, including the description of impact on reference 464 validity [I-D.ietf-opes-end-comm] (XXX: check tracing draft for this 465 requirement). 467 9. Consideration (4.3) 'Addressing extensions' 469 "Any services that cannot be achieved while respecting the above two 470 considerations may be reviewed as potential requirements for Internet 471 application addressing architecture extensions, but must not be 472 undertaken as ad hoc fixes."[RFC3238] 474 OPES framework does not contain ad hoc fixes. This document in 475 combination with and other OPES documents should be sufficient to 476 inform service creators of IAB considerations. If a service does URI 477 resolution or silently affects document reference validity, the 478 authors are requested to review service impact on Internet 479 application addressing architecture and work within IETF on potential 480 extension requirements. Such actions would be outside of the current 481 OPES framework. 483 10. Consideration (5.1) 'Privacy' 485 "The overall OPES framework must provide for mechanisms for end users 486 to determine the privacy policies of OPES intermediaries."[RFC3238] 488 OPES tracing mechanisms allow end users to identify OPES 489 intermediaries (for details, see "Notification" consideration 490 sections in this document). It is required that provided 491 identification can be used to locate information about the OPES 492 intermediaries, including their privacy policies. 494 The term "privacy policy" is not defined in this context (by IAB or 495 OPES working group). OPES tracing mechanisms allow end users and 496 content providers to identify an OPES system and/or intermediaries. 497 It is believed that once an OPES system is identified, it would be 498 possible to locate relevant information about that system, including 499 information relevant to requesters perception of privacy policy or 500 reference validity. 502 11. Consideration 'Encryption' 504 "If OPES is chartered, the OPES working group will also have to 505 explicitly decide and document whether the OPES architecture must be 506 compatible with the use of end-to-end encryption by one or more ends 507 of an OPES-involved session. If OPES was compatible with end-to-end 508 encryption, this would effectively ensure that OPES boxes would be 509 restricted to ones that are known, trusted, explicitly addressed at 510 the IP layer, and authorized (by the provision of decryption keys) by 511 at least one of the ends."[RFC3238] 513 The above quoted requirement was not explicitly listed as on of the 514 IAB considerations, but still needs to be addressed. The context of 515 the quote implies that the phrase "end-to-end encryption" refers to 516 encryption along all links of the end-to-end path, with the OPES 517 intermediaries as encrypting/decrypting participants or hops (e.g., 518 encryption between the provider and the OPES intermediaries, and 519 between the OPES intermediaries and the client). 521 Since OPES processors are regular hops on the application protocol 522 path, OPES architecture allows for such encryption, provided the 523 application protocol being adapted supports it. Hop-by-hop encryption 524 would do little good for the overall application message path 525 protection if callout services have to receive unencrypted content. 526 To allow for complete link encryption coverage, OPES callout protocol 527 (OCP) supports encryption of OCP connections between an OPES 528 processor and a callout server via optional (negotiated) transport 529 encryption mechanisms [I-D.ietf-opes-ocp-core]. 531 For example, TLS encryption [RFC2817] can be used among HTTP hops 532 (some of which could be OPES processors) and between each OPES 533 processor and a callout server. 535 12. Security Considerations 537 This document does not define any mechanisms that may be subject to 538 security considerations. Security considerations for OPES mechanisms 539 are discussed in corresponding OPES framework documents. 541 13. Compliance 543 This document may be perceived as a proof of OPES compliance with IAB 544 implied recommendations. However, this document does not introduce 545 any compliance subjects. Compliance of OPES implementations is 546 defined in other OPES documents discussed above. 548 Appendix A. Change Log 550 Internal WG revision control ID: $Id: iab-cons.xml,v 1.26 2003/10/27 551 11:40:33 rousskov Exp $ 553 2003/10/24 555 * Addressed hop-by-hop encryption concerns mentioned in the IAB 556 draft. 558 * Polished IP addressing figure. 560 * Removed resolved XXXs. 562 2003/10/01 564 * Polishing (Abbie Barbir). 566 2003/09/23 568 * Added a reference to Optional Notification section of the 569 ietf-opes-end-comm draft. 571 * Fixed "Consideration (3.3) Non-blocking" section position. 573 head-sid15 575 * Added a figure showing a chain of internal OPES intermediaries 576 behind a public IP address. Needs more work. More cases? 578 head-sid14 580 * Rewrote the Introduction to the IP addressing consideration. 581 Do NOT explain how IAB considerations, if interpreted literary, 582 do not satisfy important real-world constraints. Instead, use 583 the "chain of OPES intermediaries" exception introduced by IAB 584 itself to show that OPES architecture addresses IAB concerns as 585 long as the "chain" is defined/formed for a given application 586 message rather than being a statically configured application 587 routing table of sorts. IAB had to add the "chain" exception to 588 cover one of the most obvious real-world usage scenario. We use 589 the very same exception to cover all usage scenarios we care 590 about. 592 * Polished text explaining the differences between tracing and 593 notification mechanisms. 595 * Added examples of OPES/HTTP traces. 597 * Be careful not to imply that all OPES intermediaries must obey 598 bypass instructions. Bypass should be ignored when no non-OPES 599 version of the content exists. Ideally, this may need to be 600 polished further -- if there is no non-OPES version of the 601 content, most IAB considerations probably do not apply because 602 there is really no adaptation, only creation of content (and we 603 should not restrict content creation). 605 * Added references to OPES "Communications" draft 606 [I-D.ietf-opes-end-comm]. 608 head-sid9 610 * Polished to meet new xml2rfc strict requirements. 612 head-sid8 614 * Added unpolished meat for all nine considerations. 616 * Added Abbie Barbir as an author. 618 head-sid7 620 * Initial revision 622 Normative References 624 [I-D.ietf-opes-end-comm] 625 Barbir, A., "OPES processor and end points 626 communications", draft-ietf-opes-end-comm-04 (work in 627 progress), October 2003. 629 [I-D.ietf-opes-architecture] 630 Barbir, A., "An Architecture for Open Pluggable Edge 631 Services (OPES)", draft-ietf-opes-architecture-04 (work in 632 progress), December 2002. 634 [I-D.ietf-opes-scenarios] 635 Barbir, A., "OPES Use Cases and Deployment Scenarios", 636 draft-ietf-opes-scenarios-01 (work in progress), August 637 2002. 639 [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy 640 Considerations for Open Pluggable Edge Services", RFC 641 3238, January 2002. 643 Informative References 645 [RFC2227] Mogul, J. and P. Leach, "Simple Hit-Metering and 646 Usage-Limiting for HTTP", RFC 2227, October 1997. 648 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 649 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 650 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 652 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/ 653 1.1", RFC 2817, May 2000. 655 [I-D.ietf-opes-http] 656 Rousskov, A. and M. Stecher, "HTTP adaptation with OPES", 657 draft-ietf-opes-http-00 (work in progress), August 2003. 659 [I-D.ietf-opes-ocp-core] 660 Rousskov, A., "OPES Callout Protocol Core", 661 draft-ietf-opes-ocp-core-01 (work in progress), August 662 2003. 664 Authors' Addresses 666 Abbie Barbir 667 Nortel Networks 668 3500 Carling Avenue 669 Nepean, Ontario 670 CA 672 Phone: +1 613 763 5229 673 EMail: abbieb@nortelnetworks.com 675 Alex Rousskov 676 The Measurement Factory 678 EMail: rousskov@measurement-factory.com 679 URI: http://www.measurement-factory.com/ 681 Intellectual Property Statement 683 The IETF takes no position regarding the validity or scope of any 684 intellectual property or other rights that might be claimed to 685 pertain to the implementation or use of the technology described in 686 this document or the extent to which any license under such rights 687 might or might not be available; neither does it represent that it 688 has made any effort to identify any such rights. Information on the 689 IETF's procedures with respect to rights in standards-track and 690 standards-related documentation can be found in BCP-11. Copies of 691 claims of rights made available for publication and any assurances of 692 licenses to be made available, or the result of an attempt made to 693 obtain a general license or permission for the use of such 694 proprietary rights by implementors or users of this specification can 695 be obtained from the IETF Secretariat. 697 The IETF invites any interested party to bring to its attention any 698 copyrights, patents or patent applications, or other proprietary 699 rights which may cover technology that may be required to practice 700 this standard. Please address the information to the IETF Executive 701 Director. 703 Full Copyright Statement 705 Copyright (C) The Internet Society (2003). All Rights Reserved. 707 This document and translations of it may be copied and furnished to 708 others, and derivative works that comment on or otherwise explain it 709 or assist in its implementation may be prepared, copied, published 710 and distributed, in whole or in part, without restriction of any 711 kind, provided that the above copyright notice and this paragraph are 712 included on all such copies and derivative works. However, this 713 document itself may not be modified in any way, such as by removing 714 the copyright notice or references to the Internet Society or other 715 Internet organizations, except as needed for the purpose of 716 developing Internet standards in which case the procedures for 717 copyrights defined in the Internet Standards process must be 718 followed, or as required to translate it into languages other than 719 English. 721 The limited permissions granted above are perpetual and will not be 722 revoked by the Internet Society or its successors or assignees. 724 This document and the information contained herein is provided on an 725 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 726 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 727 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 728 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 729 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 731 Acknowledgment 733 Funding for the RFC Editor function is currently provided by the 734 Internet Society.