Network Working Group A. Barbir Internet-Draft Nortel Networks Expires: March 31, 2004 Oct. 2003 OPES entities and end points communication draft-ietf-opes-end-comm-04 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. Internet-Drafts are draft documents valid for a maximum of six months 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 March 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo documents tracing and non-blocking requirements for Open Pluggable Edge Services (OPES). Barbir Expires March 31, 2004 [Page 1] Internet-Draft OPES entities and end points communication Oct. 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements for OPES Tracing . . . . . . . . . . . . . . . . 5 3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . . 5 3.2 Requirements for OPES System . . . . . . . . . . . . . . . . . 6 3.3 Requirements for OPES processors . . . . . . . . . . . . . . . 7 3.4 Requirements for callout servers . . . . . . . . . . . . . . . 7 4. Requirements for OPES System Bypass (Non-blocking feature) . . 8 4.1 What can be bypassed in an OPES Flow? . . . . . . . . . . . . 8 4.2 Bypass requirements for OPES System . . . . . . . . . . . . . 9 4.3 Bypass requirements for OPES processors . . . . . . . . . . . 9 4.4 Bypass requirements for callout servers . . . . . . . . . . . 10 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7.1 Tracing security considerations . . . . . . . . . . . . . . . 13 7.2 Bypass security considerations . . . . . . . . . . . . . . . . 14 Normative References . . . . . . . . . . . . . . . . . . . . . 16 Informative References . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Barbir Expires March 31, 2004 [Page 2] Internet-Draft OPES entities and end points communication Oct. 2003 1. Introduction The Open Pluggable Edge Services (OPES) architecture [7] 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. This work specifies the requirements for providing tracing functionality for the OPES architecture [7]. Tracing functionality enables a data provider or a data consumer application to detect inappropriate actions that are performed by OPES entities. The work also develops requirements that can be used to fulfill IAB Notification and Bypass (Non-Blocking) requirements [2]. The architecture document requires [7] that tracing is supported in-band. This design goal limits the type of application protocols that OPES can support. The details of what a trace record can convey are also dependent on the choice of the application level protocol. For these reasons, this work documents requirements for application protocols that need to support OPES traces and non-blocking mechanism. However, the architecture does not prevent implementers of developing out-of-band protocols and techniques to address these limitation. Barbir Expires March 31, 2004 [Page 3] Internet-Draft OPES entities and end points communication Oct. 2003 2. OPES System This sections provides a definition of OPES System. This is needed in order to define what is traceable in an OPES Flow. Definition: An OPES System is a set of all OPES entities [7] authorized by either the data provider or the data consumer application to process a given application message. The nature of the authorization agreement determines if authority delegation is transitive (meaning an authorized entity is authorized to include other entities). If specific authority agreements allow for re-delegation, an OPES system can be formed by induction. In this case, an OPES system starts with entities directly authorized by a data provider (or a data consumer) application. The OPES system then includes any OPES entity authorized by an entity that is already in the OPES system. The authority delegation is always viewed in the context of a given application message. An OPES System is defined on an application message basis. Having an authority to process a message does not imply being involved in message processing. Thus, some OPES system members may not participate in processing of a message. Similarly, some members may process the same message several times. The above definition implies that there can be no more than two OPES systems [Client-side and server-side OPES systems can process the same message at the same time] processing the same message at a given time. This is based on the assumption that there is a single data provider and a single data consumer as far as a given application message is concerned. For example, consider a Content Delivery Network (CDN) delivering an image on behalf of a busy web site. OPES processors and services that the CDN uses to adapt and deliver the message comprise an OPES System. In a more complex example, an OPES System would contain CDN entries as well as 3rd-party OPES entities that CDN engages to perform adaptations (e.g., to adjust image quality). Barbir Expires March 31, 2004 [Page 4] Internet-Draft OPES entities and end points communication Oct. 2003 3. Requirements for OPES Tracing In an OPES System tracing is defined as the inclusion of necessary information within a message in an OPES Flow that identify the collection of transformations or adaptations that have been performed on it before its delivery to an end point (for example, the data consumer application). An OPES trace represents a snap shot of the tracing information that have been added to a given application message. A trace represents the collections of transformations on an application message in the order that were performed. A traceable entity can appear multiple times in a trace (every time it acts on a message). In an OPES System tracing is performed on per message basis. Trace format is dependent on the application protocol that is being adapted by OPES. A data consumer application can use OPES trace to infer the actions that have been performed by the OPES System. Actions are the set of OPES services that were performed by OPES entities in an OPES System. In an OPES System, the task of providing tracing information, can depend on many factors. Some considerations are: o Providers may be hesitant to reveal information about their internal network infrastructure. o Within a service provider network, OPES processors may be configured to use non-routable, private IP addresses. o A data consumer applications would prefer to have a single point of contact regarding the trace information. In an OPES System some OPES services are message-agnostic and operate on message content or parts of a message. Such services do not manipulate message headers. Other services can manipulate message headers. OPES providers require some freedom in the way they deliver tracing information to an end point. 3.1 What is traceable in an OPES Flow? This section focuses on identifying traceable entities in an OPES Flow. Tracing information provides a data consumer application (or a data provider application) with information about OPES entities that adapted the data. There are two distinct uses of OPES traces. First, a trace enables an "end (content provider or consumer) to detect the presence of OPES processors within an OPES System. Such "end" should Barbir Expires March 31, 2004 [Page 5] Internet-Draft OPES entities and end points communication Oct. 2003 be able to see a trace entry, but does not need to be able to interpret it beyond identification of the OPES System. Second, the OPES System administrator is expected to be able to interpret the contents of an OPES trace. The trace can be relayed to the administrator by an end (data consumer or provider) without interpretation, as opaque data (e.g., a TCP packet or an HTTP message snapshot). The administrator can use the trace information to identify the participating OPES entities. The administrator can use the trace to identify the applied adaptation services along with other message-specific information. Since the administrators of various OPES Systems can have various ways of looking into tracing, they require the choice of freedom in what to put in trace records and how to format them. Trace records should be easy to extend beyond basic OPES requirements. Trace management algorithms should treat trace records as opaque data to the extent possible. At the implementation level, for a given trace, an OPES entity involved in handling the corresponding application message is traceable or traced if information about it appears in that trace. OPES entities have different levels of traceability requirements. Specifically, o An OPES processor SHOULD add its entry to the trace. o An OPES service May add its entry to the trace. o An OPES entity MAY delegate addition of its trace entry to another OPES entity. For example, an OPES System can have a dedicated OPES processor for adding System entries; an OPES processor can use a callout service to manage all OPES trace manipulations (since such manipulations are OPES adaptations). In an OPES context, a good tracing approach is similar to a trouble ticket ready for submission to a known address. The address is printed on the ticket. The trace in itself is not necessarily a detailed description of what has happened. It is the responsibility of the operator to resolve the problems. 3.2 Requirements for OPES System The following requirements apply for information as related to an OPES System: o An OPES system MUST add its identification to the trace. Barbir Expires March 31, 2004 [Page 6] Internet-Draft OPES entities and end points communication Oct. 2003 o An OPES System MUST include information about its privacy policy. o An OPES System MUST identify the party responsible for setting and enforcing that policy. o An OPES System MUST include information pointing to a technical contact. o An OPES System MUST include information that identifies, to the technical contact, the OPES processors involved in processing the message. In addressing the above requirements and in order to reduce the size of the trace, an OPES System can provide a URL to the OPES System web page that has links to privacy and other policies. 3.3 Requirements for OPES processors Tracing requirements for OPES processors are: o Each OPES processor MUST support tracing, policy can be used to turn tracing on and to determine its granularity. o If tracing is turned on, OPES processor SHOULD add its unique identification to the trace. Here, uniqueness scope is the OPES System containing the processor. o OPES processor SHOULD be able to trace it's own invocation and service(s) execution since it understands the application protocol. 3.4 Requirements for callout servers In an OPES system, it is the task of an OPES processor to add trace records to application messages. However, in some cases, callout servers May add trace information to application messages. This should be done under the control of the OPES System provider. Barbir Expires March 31, 2004 [Page 7] Internet-Draft OPES entities and end points communication Oct. 2003 4. Requirements for OPES System Bypass (Non-blocking feature) IAB recommendation (3.3) [2] requires that the OPES architecture does not prevent a data consumer application from retrieving non-OPES version of content from a data provider application, provided that the non-OPES content exists. IAB recommendation (3.3) suggests that the Non-blocking feature (Bypass) be used to bypass faulty OPES intermediaries (once they have been identified, by some method). In addressing IAB consideration (3.3), one need to specify what constitute non-OPES content. In some cases, the definition of "non-OPES" content is provider-dependent and may include content adapted by OPES. Examples include content that is adapted for Black and White hand held devices or logging services. In other cases, the availability of certain content can be a function of the internal policy of a given organization that has contracted the services of an OPES provider. For example, Company A has as contract with an OPES provider to perform virus checking on all e-mail attachments. An employee X of Company A can issue a non-blocking request for the virus scanning service. However, the request could be ignored by the OPES provider since it contradicts its agreement with Company A. The above examples illustrates that the availability of non-OPES content can be a function of content providers (or consumers or both) policy and deployment scenarios [1]. For this reason, this work does not attempt to define what is an OPES content as opposed to non-OPES content. The meaning of OPES versus non-OPES content is assumed to be determined through various agreements between the OPES provider, data provider and data consumer application. The agreement will also determine what OPES services can be bypassed and in what order (if applicable). In an OPES System a Bypass request is defined as the act of avoiding the invocation of a service(s) that is identified by a URI within a message in an OPES Flow before its delivery to an end point (for example, the data consumer application). 4.1 What can be bypassed in an OPES Flow? In this work, the focus is on developing a bypass feature that allow a user to instruct the OPES System to bypass some or all of its services. The collection of OPES services that can be bypassed is a function of the agreement of the OPES provider with either (or both) the content provider or the content consumer applications. In the general case, a Bypass request is viewed as a bypass instruction that contains a URI that identifies an OPES entity or a group of OPES entities that perform a service (or services) to be bypassed. An instruction may contain more than one such URI. A special wildcard Barbir Expires March 31, 2004 [Page 8] Internet-Draft OPES entities and end points communication Oct. 2003 identifier can be used to represent all possible URIs (i.e., all possible OPES services). 4.2 Bypass requirements for OPES System In an OPES System the Bypass feature is an end-to-end operation as opposed to a hop-by-hop operation. Bypass requests are generally client centric and go in the opposite direction of tracing requests. Bypass can be performed out of band or in-band. This work requires that the Bypass feature be performed in-band as an extension to an application specific protocol. Non-OPES entities should be able to safely ignore these extensions. The work does not prevent OPES Systems from developing their own out of band protocols. The following requirements apply for Bypass feature as related to an OPES System: o An OPES system MUST support a Bypass feature. This means that the OPES System bypasses an entity whose URI is identified by an OPES end (usually data consumer application). o An OPES System MUST treat a Bypass request as an end-to-end operation. This applies to the whole system. o An OPES System MUST include information about its bypass policy. o An OPES System MUST identify the party responsible for setting and enforcing the bypass policy. o An OPES System MUST include information that identifies, to a technical contact, the OPES processors involved in processing the bypass request. In addressing the above requirements an OPES System can provide a URL to the OPES System web page that has links to Bypass and other policies. In order to facilitate the debugging (or data consumer user experience) of the bypass feature in an OPES System, it would be beneficial if non-bypassed entities include information related to why they ignored the bypass instruction. It is important to note that in some cases the tracing facility itself may be broken and the whole OPES System (or part) may need to be bypassed through the issue of a bypass instruction. 4.3 Bypass requirements for OPES processors For a given application protocol, in an OPES System there can be Barbir Expires March 31, 2004 [Page 9] Internet-Draft OPES entities and end points communication Oct. 2003 services that operate on application message headers and those that just operate on content. This mix of service requires that an OPES processor that is calling the service(s) to handle the bypass request. In some cases, the first OPES processor that will get the bypass request may not be the first OPES processor that will know whether a non-OPES version of the content is available or not. Bypass requirements for OPES processors are: o There MUST be at least one OPES processor in an OPES System that knows how to interpret and process a bypass request. This requirement applies to all bypass instructions, including those that identify known-to-recipient entities. o OPES processors that do not know how to process a bypass request MUST forward the request to the next application hop provided that the next hop speaks application protocol with OPES bypass support. o The recipient of a bypass instruction with a URI that does not identify any known-to-recipient OPES entity MUST treat that URI as a wildcard identifier (meaning bypass all applicable services). o OPES processor SHOULD be able to bypass it's own invocation and service(s) execution since it understands the application protocol. 4.4 Bypass requirements for callout servers In an OPES system, it is the task of an OPES processor to process bypass requests. However, in some cases, callout servers May be involved in processing Bypass requests. This should be done under the control of the OPES System provider. Barbir Expires March 31, 2004 [Page 10] Internet-Draft OPES entities and end points communication Oct. 2003 5. Protocol Binding The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols. Barbir Expires March 31, 2004 [Page 11] Internet-Draft OPES entities and end points communication Oct. 2003 6. IANA considerations This specification contains no IANA considerations. Application bindings MAY contain application-specific IANA considerations. Barbir Expires March 31, 2004 [Page 12] Internet-Draft OPES entities and end points communication Oct. 2003 7. Security Considerations The security considerations for OPES are documented in [6]. This document is a requirement document for tracing and Bypass feature. The requirements that are stated in this document can be used to extend an application level protocol to support these features. As such, the work has security precautions. 7.1 Tracing security considerations The tracing facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the tracing facility may defeat safeguards built into the OPES architecture. The tracing facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the tracing facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. Since tracing information is a protocol extension, these traces can be injected in the data flow by non-OPES entities. In this case, there are risks that non-OPES entities can be compromised in a fashion that threat the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy can add fake tracing information into a trace. This can be done in the form of wrong, or unwanted, or non existent services. A non-OPES entity can inject large size traces that may cause buffer overflow in a data consumer application. The same threats can arise from compromised OPES entities. An attacker can control an OPES entity and inject wrong, or very large trace information that can overwhelm an end or the next OPES entity in an OPES flow. Similar threats can result from bad implementations of the tracing facility in trusted OPES entities. Compromised tracing information can be used to launch attacks on an OPES System that give the impression that unwanted content transformation was performed on the data. This can be achieved by inserting wrong entity (such OPES processor) identifiers. A compromised trace can affect the overall message integrity structure. This can affect entities that use message header information to perform services such as accounting, load balancing, or reference-based services. Compromised trace information can be used to launch DoS attacks that can overwhelm a data consumer application or an OPES entity in an OPES Flow. Inserting wrong tracing information can complicates the debugging tasks performed by system administrator during trouble Barbir Expires March 31, 2004 [Page 13] Internet-Draft OPES entities and end points communication Oct. 2003 shooting of OPES System behavior. Specific protocol binding documents ought to take these security threats into consideration. It is recommended that protocol bindings provide safe features into their specifications. Such features may include a place holder in the message header that indicates the size of the trace. Other holders can include the option of signing the trace information as a proof of authenticity. As a precaution, OPES entities ought to be capable of verifying that the inserted traces are performed by legal OPES entities. This can be done as part of the authorization and authentication face. Policy can be used to indicate what trace information can be expected from a peer entity. Other application level related security concerns can be found in [6]. 7.2 Bypass security considerations The bypass facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the bypass facility may defeat safeguards built into the OPES architecture. The bypass facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the bypass facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. There are risks for the OPES System by non-OPES entities, whereby, these entities can insert bypass instructions into the OPES Flow. The threat can come from compromised non-OPES entities. The threat might affect the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy can add bypass instruction to bypass legitimate OPES entities. The attack might result in overwhelming the original content provider servers, since the attack essentially bypass any load balancing techniques. In addition, such an attack is also equivalent to a DoS attack, whereby, a legitimate data consumer application may not be able to access some content from a content provider or its OPES version. Since an OPES Flow may include non-OPES entities, it is susceptible to man-in-the-middle attacks, whereby an intruder may inject bypass instructions into the data path. These attacks may affect content availability or disturb load balancing techniques in the network. The above threats can also arise by compromised OPES entities. An intruder can compromise an OPES entities and then use Barbir Expires March 31, 2004 [Page 14] Internet-Draft OPES entities and end points communication Oct. 2003 man-in-the-middle techniques to disturb content availability to a data consumer application or overload a content provider server (essentially, some form of a DoS attack). Attackers can use the bypass instruction to affect the overall integrity of the OPES System. The ability to illegally introduce bypass instructions into a data flow may effect the accounting of the OPES System. It may also affect the quality of content that is delivered to the data consumer applications. Similar threats can arise from bad implementations of the bypass facility. Specific protocol binding documents ought to take these security threats into consideration. It is recommended that protocol bindings provide safe features into their specifications. Such features may include a place holder in the message header that indicates who originated the bypass request. Other holders can include the option of signing the bypass request as a proof of identity. Other application level related security concerns can be found in [6]. Barbir Expires March 31, 2004 [Page 15] Internet-Draft OPES entities and end points communication Oct. 2003 Normative References [1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-scenarios-01.txt, August 2002. Barbir Expires March 31, 2004 [Page 16] Internet-Draft OPES entities and end points communication Oct. 2003 Informative References [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [4] A. Barbir et al., "Policy, Authorization and Enforcement Requirements of OPES", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-authorization-02.txt, February 2003. [5] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD, September 2003. [6] A. Barbir et al., "Security Threats and Risks for Open Pluggable Edge Services", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. [7] A. Barbir et al., "An Architecture for Open Pluggable Edge Services (OPES)", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-architecture-04, December 2002. [8] A. Barbir et al., "OPES Treatment of IAB Considerations", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-iab-02.txt, February 2004. Author's Address Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir Expires March 31, 2004 [Page 17] Internet-Draft OPES entities and end points communication Oct. 2003 Appendix A. Acknowledgements Several people has contributed to this work. Many thanks to: Alex Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin Stecher, Marshall Rose and Reinaldo Penno. Barbir Expires March 31, 2004 [Page 18] Internet-Draft OPES entities and end points communication Oct. 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can 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. 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 developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir Expires March 31, 2004 [Page 19] Internet-Draft OPES entities and end points communication Oct. 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir Expires March 31, 2004 [Page 20]