--- 1/draft-ietf-opes-iab-04.txt 2006-02-05 00:56:05.000000000 +0100 +++ 2/draft-ietf-opes-iab-05.txt 2006-02-05 00:56:05.000000000 +0100 @@ -1,19 +1,19 @@ Open Pluggable Edge Services A. Barbir Internet-Draft Nortel Networks -Expires: June 1, 2004 A. Rousskov +Expires: October 11, 2004 A. Rousskov The Measurement Factory - December 2, 2003 + April 12, 2004 OPES Treatment of IAB Considerations - draft-ietf-opes-iab-04 + draft-ietf-opes-iab-05 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -21,57 +21,57 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 1, 2004. + This Internet-Draft will expire on October 11, 2004. Copyright Notice - Copyright (C) The Internet Society (2003). All Rights Reserved. + Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 5 4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 6 5. Notification Considerations . . . . . . . . . . . . . . . . . 8 5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8 - 5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9 + 5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 10 5.3 Consideration (3.1) 'Notification' . . . . . . . . . . . . . . 11 5.4 Consideration (3.2) 'Notification' . . . . . . . . . . . . . . 12 6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 13 7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 14 8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 15 9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 16 10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 17 11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 20 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - Normative References . . . . . . . . . . . . . . . . . . . . . 23 - Informative References . . . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 - Intellectual Property and Copyright Statements . . . . . . . . 25 + Normative References . . . . . . . . . . . . . . . . . . . . . 24 + Informative References . . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 + Intellectual Property and Copyright Statements . . . . . . . . 26 1. Introduction The Open Pluggable Edge Services (OPES) architecture [I-D.ietf-opes-architecture], enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. @@ -79,71 +79,91 @@ issues that OPES solutions should be required to address. These recommendations were formulated in the form of a specific IAB considerations document [RFC3238]. In that document, IAB emphasized that its considerations did not recommend specific solutions and did not mandate specific functional requirements. Addressing an IAB consideration may involve showing appropriate protocol mechanisms or demonstrating that the issue does not apply. Addressing a consideration does not necessarily mean supporting technology implied by the consideration wording. - The primary goal of this document is to show that all IAB + The primary goal of this document is to show that all formal IAB recommendations are addressed by OPES, to the extent that those considerations can be addressed by an IETF working group. The limitations of OPES working group to address certain aspects of IAB considerations are also explicitly documented. - There are nine IAB considerations [RFC3238] that OPES has to address. - In the core of this document are the corresponding nine + IAB considerations document [RFC3238] contains many informal + recommendations. For example, while the IAB informally requires OPES + architecture to "protect end-to-end data integrity by supporting + end-host detection and response to inappropriate behavior by OPES + intermediaries", the IAB has chosen to formalize these requirements + via a set of more specific recommendations, such as Notification + considerations addressed in Section 5.3 and Section 5.4 below. OPES + framework addresses informal IAB recommendations by addressing + corresponding formal considerations. + + There are nine formal IAB considerations [RFC3238] that OPES has to + address. In the core of this document are the corresponding nine "Consideration" sections. For each IAB consideration, its section contains general discussion as well as references to specific OPES mechanisms relevant to the consideration. 2. Terminology This document does not introduce any new terminology but uses terminology from other OPES documents it quotes. 3. Consideration (2.1) 'One-party consent' "An OPES framework standardized in the IETF must require that the use of any OPES service be explicitly authorized by one of the application-layer end-hosts (that is, either the content provider or the client)."[RFC3238] OPES architecture requires that "OPES processors MUST be consented to by either the data consumer or data provider application" - [I-D.ietf-opes-architecture]. This requirement alone cannot prevent - consent-less introduction of OPES processors. In - [I-D.ietf-opes-end-comm], the OPES architecture enables concerned - parties to detect unwanted OPES processors by examining OPES traces. - The use of traces in OPES is mandatory. + [I-D.ietf-opes-architecture]. While this requirement directly + satisfies IAB concern, no requirement alone can prevent consent-less + introduction of OPES processors. In other words, OPES framework + requires one-party consent but cannot guarantee it in the presence of + incompliant OPES entities. - A tracing mechanism on its own cannot detect processors that are in - violation of OPES specifications. Examples include OPES processors - operating in stealth mode. However, the OPES architecture allows the - use of content signature to verify the authenticity of performed + In [I-D.ietf-opes-end-comm], the OPES architecture enables concerned + parties to detect unwanted OPES processors by examining OPES traces. + While the use of traces in OPES is mandatory, a tracing mechanism on + its own cannot detect processors that are in violation of OPES + specifications. Examples include OPES processors operating in + stealth mode. However, the OPES architecture allows the use of + content signature to verify the authenticity of performed adaptations. Content signatures is a strong but expensive mechanism that can detect any modifications of signed content provided that the content provider is willing to sign the data and that the client is willing to either check the signature or relay received content to the content provider for signature verification. - OPES adaptations may include copying and other forms of non-modifying - access to content. These kinds of adaptations cannot be detected by - the above mentioned mechanisms. Thus, "passive" OPES processors can - operate on the content without the data consumer or provider consent. - If presence of such processors is a concern, then content encryption - can be used. A passive processor is no different from a proxy or an - intermediary operating outside of OPES framework. No OPES mechanism - (existing or foreseeable) can prevent non-modifying access to - content. + OPES entities may copy or otherwise access content without modifying + it. Such access cannot be detected using content signatures. Thus, + "passive" OPES entities can operate on signed content without the + data consumer or provider consent. If content privacy is a concern, + then content encryption can be used. A passive processor is no + different from any intermediary operating outside of OPES framework. + No OPES mechanism (existing or foreseeable) can prevent non-modifying + access to content. + + In summary, the one-party consent is satisfied by including the + corresponding requirement in the IAB architecture document. That + requirement alone cannot stop incompliant OPES entities to perform + consent-less adaptations, but OPES framework allows for various means + of detecting and/or preventing such adaptations. These means + typically introduce overheads and require some level of + producer-consumer cooperation. 4. Consideration (2.2) 'IP-layer communications' "For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addressed at the IP layer by the end user."[RFC3238] The OPES architecture requires that "OPES processors MUST be addressable at the IP layer by the end user (data consumer application)" [I-D.ietf-opes-architecture]. The IAB and the @@ -231,21 +252,21 @@ ^ V [with trace] | | +-<-- [notification] ---+ Figure 2 Since notifications cannot be piggy-backed to application messages, they create new messages and may double the number of messages the sender has to process. The number of messages that need to be proceed is larger if several intermediaries on the message path generate - notifications). Associating notifications with application messages + notifications. Associating notifications with application messages may require duplicating application message information in notifications and may require maintaining a sender state until notification is received. These actions increase the performance overhead of notifications. The level of available details in notifications versus provider interest in supporting notification is another concern. Experience shows that content providers often require very detailed information about user actions to be interested in notifications at all. For example, Hit Metering protocol [RFC2227] has been designed to supply @@ -268,31 +289,47 @@ Thus, instead of explicitly supporting notifications at the protocol level, OPES concentrates on tracing facilities. In essence, OPES supports notifications indirectly, using tracing facilities. In other words, the IAB choice of "Notification" label is interpreted as "Notification assistance" (i.e. making notifications meaningful) and is not interpreted as a "Notification protocol". The above concerns call for making notification optional. The OPES architecture allows for an efficient and meaningful notification protocol to be implemented in certain OPES environments. For - example, a Cable Company Internet Service Provider (Cable ISP) may - provide a user-configurable porn filtering service to its subscribers - while having an agreement with the parent Cable Company to send - notifications to the content provider when clients (content - consumers) use the same filter to block Company's advertisement - images. If the Cable Company deems such subscriber actions - inappropriate, the company may contact individual subscribers and - enforce their ISP usage policy according to the terms of the service - agreement. In this example, ISP cooperation is expected, the volume - of notifications would be relatively low, and notifications can be - handled in an automated manner. + example, an OPES callout server attached to a gateway or firewall may + scan outgoing traffic for signs of worm or virus activity and notify + a local Intrusion Detection System (IDS) of potentially compromised + hosts (e.g., servers or client PCs) inside the network. Such + notifications may use OPES tracing information to pinpoint the + infected host (which could be another OPES entity). In this example, + notifications are essentially sent back to the content producer (the + local network) and use OPES tracing to supply details. + + Another environment where efficient and meaningful notification using + OPES tracing is possible are Content Delivery Networks (CDNs). A CDN + node may use multiple content adaptation services to customize + generic content supplied by the content producer (a web site). For + example, a callout service may insert advertisements for client-local + events. The CDN node itself may not understand specifics of the ad + insertion algorithm implemented at callout servers. However, the + node may use information in the OPES trace (e.g., coming from the + callout service) to notify the content producer. Such notifications + may be about the number of certain advertisements inserted (i.e., the + number of "impressions" delivered to the customer) or even the number + of ad "clicks" the customer made (e.g., if the node hosts content + linked from the ads). Callout services doing ad insertion may lack + details (e.g., a customer ID/address or a web server authentication + token) to contact the content producer directly in this case. Thus, + OPES trace produced by an OPES service becomes essential in enabling + meaningful notifications that the CDN node sends to the content + producer. 5.2 An example of an OPES trace for HTTP The example below illustrates adaptations done to HTTP request at an OPES processor operated by the client ISP. Both original (as sent by an end user) and adapted (as received by the origin web server) requests are shown. The primary adaptation is the modification of HTTP "Accept" header. The secondary adaptation is the addition of an OPES-System HTTP extension header [I-D.ietf-opes-http]. @@ -444,26 +482,36 @@ notification-related considerations above. 7. Consideration (4.1) 'URI resolution' "OPES documentation must be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself."[RFC3238] "OPES Scenarios and Use Cases" specification [I-D.ietf-opes-scenarios] documents content adaptations that are in - scope of the OPES framework. Scenarios include adaptations of - requests and responses. These adaptations do not include URI - resolution adaptations. In some environments, it is technically - possible to adapt URIs (and other kinds of identifiers or addresses) - using documented OPES mechanisms. The OPES framework cannot - effectively prohibit any specific adaptations. + scope of the OPES framework. Scenarios include content adaptation of + requests and responses. These documented adaptations do not include + URI resolution. In some environments, it is technically possible to + use documented OPES mechanisms to resolve URIs (and other kinds of + identifiers or addresses). The OPES framework cannot effectively + prevent any specific kind of adaptation. + + For example, a CDN node may substitute domain names in URLs with + CDN-chosen IP addresses, essentially performing a URI resolution on + behalf of the content producer (i.e., the web site owner). An OPES + callout service running on a user PC may rewrite all HTML-embedded + advertisement URLs to point to a user-specified local image, + essentially performing a URI redirection on behalf of the content + consumer (i.e., the end user). Such URI manipulations are outside of + the OPES framework scope, but cannot be effectively eliminated from + the real world. 8. Consideration (4.2) 'Reference validity' "All proposed services must define their impact on inter- and intra-document reference validity."[RFC3238] The OPES framework does not propose adaptation services. However, OPES tracing requirements include identification of OPES intermediaries and services (for details, see "Notification" consideration sections in this document). It is required that @@ -535,37 +583,82 @@ processor and a callout server via optional (negotiated) transport encryption mechanisms [I-D.ietf-opes-ocp-core]. For example, TLS encryption [RFC2817] can be used among HTTP hops (some of which could be OPES processors) and between each OPES processor and a callout server. 12. Security Considerations This document does not define any mechanisms that may be subject to - security considerations. Security considerations for OPES mechanisms - are discussed in corresponding OPES framework documents. + security considerations. This document scope is to address specific + IAB considerations. Security of OPES mechanisms are discussed in + Security Considerations sections of the corresponding OPES framework + documents. + + For example, OPES tracing mechanisms assist content providers and + consumers in protecting content integrity and confidentiality by + requiring OPES intermediaries to disclose their presence. Security of + the tracing mechanism is discussed in the Security Considerations + section of [I-D.ietf-opes-end-comm]. 13. Compliance This document may be perceived as a proof of OPES compliance with IAB implied recommendations. However, this document does not introduce any compliance subjects. Compliance of OPES implementations is defined in other OPES documents discussed above. Appendix A. Change Log RFC Editor Note: This section is to be removed during the final publication of the document. - Internal WG revision control ID: $Id: iab-cons.xml,v 1.32 2003/12/03 - 06:46:04 rousskov Exp $ + Internal WG revision control ID: $Id: iab-cons.xml,v 1.36 2004/04/12 + 16:06:52 rousskov Exp $ + + 2004/04/08 + + * Replaced "Cable Company ISP" Notification example with two new + examples to address IESG uncertainty about the meaning of the + old convoluted example. + + * Polished text addressing "One-party consent" concern to better + show why the concern is addressed. It is not clear whether the + changes will address IESG review comment that "the WG does not + seem to get it" [because?] the text does not "name situations + where one-party consent does make sense". It is currently not + clear how naming such situations can address IAB concern, and + why naming such situations is in this document scope. + + * Polished text discussing URI resolution consideration to talk + more specifically about the resolution of URIs rather than + (more general) adaptation of URIs and added examples. This + change is meant to address IESG concern that URI resolution is + not addressed or the corresponding description is confusing. + + * Clarified in the Introduction that the purpose of this document + is to address nine formal IAB considerations, and that we hope + that addressing formal consideration is sufficient to address + any informal ones that are scattered through the IAB + Considerations document. This is meant to address IESG concern + that some [informal] words from the IAB Consideration document + do not explicitly appear in this document. + + * Be more specific about where security of OPES mechanisms is + discussed. Added an example of where security of OPES tracing + mechanisms is discussed. This document is about addressing + specific IAB considerations and is not a map/index to OPES + mechanisms or their security. However, polished text and + example may provide the reader with more direct clues on where + to find security-related information that goes beyond the scope + of this document. 2003/11/18 * Added an example where an efficient and meaningful notification protocol can be implemented in OPES. * Assume Communications draft will contain wording about documenting impact on reference validity. * Use OPES-System HTTP header for examples and mention OPES-Via. @@ -636,23 +730,23 @@ * Added Abbie Barbir as an author. head-sid7 * Initial revision Normative References [I-D.ietf-opes-end-comm] - Barbir, A., "OPES processor and end points - communications", draft-ietf-opes-end-comm-05 (work in - progress), October 2003. + Barbir, A., "OPES entities and end points communication", + draft-ietf-opes-end-comm-06 (work in progress), December + 2003. [I-D.ietf-opes-architecture] Barbir, A., "An Architecture for Open Pluggable Edge Services (OPES)", draft-ietf-opes-architecture-04 (work in progress), December 2002. [I-D.ietf-opes-scenarios] Barbir, A., "OPES Use Cases and Deployment Scenarios", draft-ietf-opes-scenarios-01 (work in progress), August 2002. @@ -716,21 +810,21 @@ be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement - Copyright (C) The Internet Society (2003). All Rights Reserved. + Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of