--- 1/draft-ietf-opes-end-comm-05.txt 2006-02-05 00:55:57.000000000 +0100 +++ 2/draft-ietf-opes-end-comm-06.txt 2006-02-05 00:55:57.000000000 +0100 @@ -1,17 +1,17 @@ -Network Working Group A. Barbir +Open Pluggable Edge Services A. Barbir Internet-Draft Nortel Networks -Expires: March 31, 2004 Oct. 2003 +Expires: May 31, 2004 Dec. 2003 OPES entities and end points communication - draft-ietf-opes-end-comm-05 + draft-ietf-opes-end-comm-06 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. @@ -19,93 +19,98 @@ 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. + This Internet-Draft will expire on May 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 10 - 4.4 Bypass requirements for callout servers . . . . . . . . . . . 10 + 3. Tracing Requirements . . . . . . . . . . . . . . . . . . . . . 5 + 3.1 Traceable entities . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2 System requirements . . . . . . . . . . . . . . . . . . . . . 6 + 3.3 Processor requirements . . . . . . . . . . . . . . . . . . . . 7 + 3.4 Callout server requirements . . . . . . . . . . . . . . . . . 7 + 4. Bypass (Non-blocking feature) Requirements . . . . . . . . . . 8 + 4.1 Bypassable entities . . . . . . . . . . . . . . . . . . . . . 9 + 4.2 System requirements . . . . . . . . . . . . . . . . . . . . . 9 + 4.3 Processor requirements . . . . . . . . . . . . . . . . . . . . 10 + 4.4 Callout server requirements . . . . . . . . . . . . . . . . . 10 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 11 6. Compliance Considerations . . . . . . . . . . . . . . . . . . 12 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8.1 Tracing security considerations . . . . . . . . . . . . . . . 14 8.2 Bypass security considerations . . . . . . . . . . . . . . . . 15 Normative References . . . . . . . . . . . . . . . . . . . . . 17 Informative References . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20 1. Introduction - The Open Pluggable Edge Services (OPES) architecture [8] enables + The Open Pluggable Edge Services (OPES) architecture [1] 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 [8]. 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]. + This work specifies OPES tracing and bypass functionality. The + architecture document [1] requires 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 only documents requirements for OPES entities that + are needed to support traces and bypass functionality. The task of + encoding tracing and bypass features is application protocol + specific. Separate documents will address HTTP and other protocols. - The architecture document requires [8] 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. + The architecture does not prevent implementers from developing + out-of-band protocols and techniques to address tracing and bypass. + Such protocols are out of scope of the current work. - For these reasons, this work documents requirements for application - protocols that need to support OPES traces and non-blocking - mechanism. The architecture does not prevent implementers of - developing out-of-band protocols and techniques to address these - limitation. In this document the key words that are used to signify - requirements are based on RFC 2119 [3]. +1.1 Terminology + + The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [2]. When + used with the normative meanings, these keywords will be all + uppercase. Occurrences of these words in lowercase comprise normal + prose usage, with no normative implications. 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. + order to define what is traceable (or bypassable) in an OPES Flow. - Definition: An OPES System is a set of all OPES entities [8] - authorized by either the data provider or the data consumer - application to process a given application message. + Definition: An OPES System is a set of all OPES entities 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. @@ -120,321 +125,321 @@ 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). - -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. + the CDN uses to adapt and deliver the image comprise an OPES System. + In a more complex example, an OPES System would contain third party + OPES entities that the CDN engages to perform adaptations (e.g., to + adjust image quality). - In an OPES System, the task of providing tracing information, can - depend on many factors. Some considerations are: +3. Tracing Requirements - o Providers may be hesitant to reveal information about their - internal network infrastructure. + The definition of OPES trace and tracing are given next. - o Within a service provider network, OPES processors may be - configured to use non-routable, private IP addresses. + OPES trace: application message information about OPES entities + that adapted the message. - o A data consumer applications would prefer to have a single point - of contact regarding the trace information. + OPES tracing: the process of creating, manipulating, or + interpreting an OPES trace. - 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. + Note that the above trace definition assumes in-band tracing. This + dependency can be removed if desired. Tracing is performed on per + message basis. Trace format is dependent on the application protocol + that is being adapted. A traceable entity can appear multiple times + in a trace (for example, every time it acts on a message). -3.1 What is traceable in an OPES Flow? +3.1 Traceable entities 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 - be able to see a trace entry, but does not need to be able to - interpret it beyond identification of the OPES System. + Tracing information provides an "end" with information about OPES + entities that adapted the data. There are two distinct uses of OPES + traces. First, a trace enables an "end" to detect the presence of + OPES System. Such "end" should be able to see a trace entry, but does + not need to be able to interpret it beyond identification of the OPES + System and location of certain required OPES-related disclosures (see + Section 3.2). 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. + the administrator by an "end" 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. + ways of looking into tracing, they require the freedom in what to put + in trace records and how to format them. 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. + This work does not specify any order to that information. The order + of information in a trace can be OPES System specific or can be + defined by application bindings documents. + OPES entities have different levels of traceability requirements. Specifically, - o An OPES processor MUST add its entry to the trace. + o An OPES System MUST add its entry to the trace. + + 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 + of the operator to decode trace details and to resolve the problems. - The following requirements apply for information as related to an - OPES System: +3.2 System requirements - o An OPES System MUST trace itself. + The following requirements document actions when forming an OPES + System trace entry: - o An OPES System MUST include information about its privacy policy. + o OPES system MUST include its unique identification in its trace + entry. Here, uniqueness scope is all OPES Systems that may adapt + the message being traced. - o An OPES System MUST identify the party responsible for setting and - enforcing that policy. + o An OPES System MUST define its impact on inter- and intra-document + reference validity. - o An OPES System MUST include information pointing to a technical - contact. + o An OPES System MUST include information about its privacy policy, + including identity of the party responsible for setting and + enforcing the policy. - o An OPES System MUST include information that identifies, to the + o An OPES System SHOULD include information that identifies, to the technical contact, the OPES processors involved in processing the message. o When providing required information, an OPES System MAY use a single URI to identify a resource containing several required items. For example, an OPES System can point to a single web page with a reference to System privacy policy and technical contact information. This specification does not define the meaning of the terms privacy - policy, policy enforcement, or technical contact and contains no - requirements regarding encoding, language, format, or any other - aspects of that information. Furthermore, an example of System - identification would be something like http://www.examplecompany.com/ - opes/?client=example.com. + policy, policy enforcement, or reference validity or technical + contact and contains no requirements regarding encoding, language, + format, or any other aspects of that information. For example, a URI + used for an OPES System trace entry may look like "http:// + www.examplecompany.com/opes/?client=example.com" where the identified + web page is dynamically generated and contains the all OPES System + information required above. -3.3 Requirements for OPES processors +3.3 Processor requirements - Tracing requirements for OPES processors are: + The following requirements document actions when forming an OPES + System trace entry: - o OPES processor MUST add its unique identification to the trace. + o OPES processor SHOULD add its unique identification to the trace. Here, uniqueness scope is the OPES System containing the processor. - o OPES processor MUST be able to trace it's own invocation and - service(s) execution. - -3.4 Requirements for callout servers +3.4 Callout server requirements 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. + records to application messages. The OPES System administrator + decides if and under what conditions callout servers may add trace + information to application messages. -4. Requirements for OPES System Bypass (Non-blocking feature) +4. Bypass (Non-blocking feature) Requirements - IAB recommendation (3.3) [2] requires that the OPES architecture does + IAB recommendation (3.3) [4] 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 + 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 this work the definition of - "non-OPES" content is provider dependent. However, in some cases, the - availability of "non-OPES" content can also 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. + constitutes non-OPES content. In this work the definition of + "non-OPES" content is provider dependent. In some cases, the + availability of "non-OPES" 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. 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). + The availability of non-OPES content can be a function of content + providers (or consumers or both) policy and deployment scenarios [3]. + 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/or data + consumer. The agreement determines 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). The availability of non-OPES - content is a precondition to whether a bypass instruction is honored - or not in an OPES System. + This specification documents bypassing of an OPES service or a group + of services identified by a URI. In this context, to "bypass the + service" for a given application message in an OPES Flow means to + "not invoke the service" for that application message. A bypass URI + that identifies an OPES system (processor) matches all services + attached to that OPES system (processor). However, bypassing of OPES + processors and OPES Systems themselves requires non-OPES mechanisms + and is out of this specification scope. A bypass request an + instruction to bypass, usually embedded in an application message. -4.1 What can be bypassed in an OPES Flow? + The current specification does not provide for a good mechanism that + allow and "end" to specify to "bypass this service but only if it is + a part of that OPES system" or "bypass all services of that OPES + system but not of this OPES system". Furthermore, if an OPES + processor does not know for sure that a bypass URI does not match its + service, it must bypass that service. + + If no non-OPES content is available without the specified service, + the bypass request for that service must be ignored. This design + implies that it may not be possible to detect non-OPES content + existence or to detect violations of bypass rules in the environments + where the tester does not know whether non-OPES content exists. This + design assumes that most bypass requests are intended for situations + where serving undesirable OPES content is better than serving an + error message that no preferred non-OPES content exists. + +4.1 Bypassable entities 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 - identifier can be used to represent all possible URIs (i.e., all - possible OPES services that are relevant to an OPES processor). + identifier can be used to represent all possible URIs. - In an OPES Flow, a bypass request is processed in a local manner by - each involved OPES processor. This means that an OPES processor - examines the bypass instruction and if non-OPES content is available, - the processor then bypasses services that are local to itself. This - may include the act of bypassing itself completely depending on what - is specified in the URI. The request is then forwarded to the next - OPES processor in the OPES Flow. The next OPES processor would then - honor all bypass requests that are relevant to it provided that the - non-OPES content is available. The processing chain continues - throughout the whole processors that are involved in the OPES Flow. - If an OPES processor does not know how to honor a bypass request it - forwards the message to the next processor in the OPES Flow. At the - OPES system level, a bypass instruction is honored when at least one - OPES processor bypasses the services that are specified by the URI - that is specified in the instruction (provided that the non-OPES - content is available). + In an OPES Flow, a bypass request is processed by each involved OPES + processor. This means that an OPES processor examines the bypass + instruction and if non-OPES content is available, the processor then + bypasses the indicated services. The request is then forwarded to the + next OPES processor in the OPES Flow. The next OPES processor would + then handle all bypass requests, regardless of the previous processor + actions. The processing chain continues throughout the whole + processors that are involved in the OPES Flow. -4.2 Bypass requirements for OPES System +4.2 System requirements - In an OPES System 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 + In an OPES System bypass requests are generally client centric + (originated by the data consumer application) and go in the opposite + direction of tracing requests. 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 + The following requirements apply for bypass feature as related to an OPES System (the availability of a non-OPES content is a precondition) : - 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 support a bypass feature. This means that the + OPES System bypasses services whose URIs are identified by an OPES + "end". + + o An OPES System MUST provide OPES version of the content if + non-OPES version is not available. 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 - 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. +4.3 Processor requirements Bypass requirements for OPES processors are (the availability of a non-OPES content is a precondition): o OPES processor SHOULD be able to interpret and process a bypass instruction. This requirement applies to all bypass instructions, - including those that identify known-to-recipient services. + including those that identify unknown-to-recipient services. - 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 OPES processors MUST forward bypass request to the next + application hop provided that the next hop speaks application + protocol with OPES bypass support. o OPES processor SHOULD be able to bypass it's service(s) execution. - Provided that non-OPES content is available, those OPES processors - that know how to process and interpret a bypass instruction have the - following requirements: + OPES processors that know how to process and interpret a bypass + instruction have the following requirements: 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 local - services). + a wildcard identifier (meaning bypass all applicable services). -4.4 Bypass requirements for callout servers +4.4 Callout server requirements 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. + bypass requests. The OPES System administrator decides if and under + what conditions callout servers process bypass requests. 5. Protocol Binding The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other - protocols. + protocols. These documents must address the ordering of trace + information if needed. 6. Compliance Considerations - This work specifies high level requirements for tracing and bypass. - Protocol binding specifications MUST consider and follow all MUSTs in - this draft. Protocol binding specifications MUST be compliant to this - draft. As such any implementation compliant to the binding - specification is also compliant to this draft. + This specification defines compliance for the following compliance + subjects: OPES System, processors, entities and callout servers. + + A compliance subject is compliant if it satisfies all applicable + "MUST" and "SHOULD" level requirements. By definition, to satisfy a + "MUST" level requirement means to act as prescribed by the + requirement; to satisfy a "SHOULD" level requirement means to either + act as prescribed by the requirement or have a reason to act + differently. A requirement is applicable to the subject if it + instructs (addresses) the subject. + + Informally, compliance with this draft means that there are no known + "MUST" violations, and all "SHOULD" violations are conscious. In + other words, a "SHOULD" means "MUST satisfy or MUST have a reason to + violate". It is expected that compliance claims are accompanied by a + list of unsupported SHOULDs (if any), in an appropriate format, + explaining why preferred behavior was not chosen. + + Only normative parts of this specification affect compliance. + Normative parts are: parts explicitly marked using the word + "normative", definitions, and phrases containing unquoted capitalized + keywords from [RFC2119]. Consequently, examples and illustrations are + not normative. 7. IANA considerations This specification contains no IANA considerations. Application bindings MAY contain application-specific IANA considerations. 8. Security Considerations - The security considerations for OPES are documented in [7]. This - document is a requirement document for tracing and Bypass feature. + The security considerations for OPES are documented in [8]. 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. 8.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 @@ -472,21 +477,21 @@ 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 shooting of OPES System behavior. 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 [7]. + found in [8]. 8.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 @@ -538,61 +543,61 @@ Tap bypass can also be a threat. This is because systems implementing wiretaps via OPES entities may be incorrectly configured to honor bypass and, hence, ignore (leave undetected) traffic with bypass instructions that should have been tapped or logged. It is also possible for one end to bypass services such as virus scanning at the receiving end. This threat can be used by hackers to inject viruses throughout the network. Other application level related security concerns can be found in - [7]. + [8]. 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. + [1] 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. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. Informative References - [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy + [3] 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. + + [4] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. - [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - - [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., + [5] 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. - [5] A. Barbir et al., "Policy, Authorization and Enforcement + [6] 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. - [6] Rousskov, A. et al, "HTTP adaptation with OPES", Internet-Draft - http://www.ietf.org/internet-drafts/draft-ietf-opes-http-00.txt, - July 2003. + [7] Rousskov, A. et al, "HTTP adaptation with OPES", Internet-Draft + http://www.ietf.org/internet-drafts/draft-ietf-opes-http-01.txt, + October 2003. - [7] A. Barbir et al., "Security Threats and Risks for Open Pluggable + [8] 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. - [8] 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. - [9] A. Barbir et al., "OPES Treatment of IAB Considerations", Internet-Draft http://www.ietf.org/internet-drafts/ - draft-ietf-opes-iab-02.txt, September 2003. + draft-ietf-opes-iab-03.txt, October 2003. Author's Address Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229