idnits 2.17.1 draft-ietf-opes-end-comm-06.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 323 has weird spacing: '...ces) to be by...' == Line 372 has weird spacing: '...cluding those...' == Line 545 has weird spacing: '...ic with bypas...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2119' on line 423 == Unused Reference: '5' is defined on line 573, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 577, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 582, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 590, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '5') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-05) exists of draft-ietf-opes-iab-03 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Open Pluggable Edge Services A. Barbir 2 Internet-Draft Nortel Networks 3 Expires: May 31, 2004 Dec. 2003 5 OPES entities and end points communication 6 draft-ietf-opes-end-comm-06 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at http:// 23 www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on May 31, 2004. 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 This memo documents tracing and non-blocking (bypass) requirements 37 for Open Pluggable Edge Services (OPES). 39 Table of Contents 41 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 42 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 4 44 3. Tracing Requirements . . . . . . . . . . . . . . . . . . . . . 5 45 3.1 Traceable entities . . . . . . . . . . . . . . . . . . . . . . 5 46 3.2 System requirements . . . . . . . . . . . . . . . . . . . . . 6 47 3.3 Processor requirements . . . . . . . . . . . . . . . . . . . . 7 48 3.4 Callout server requirements . . . . . . . . . . . . . . . . . 7 49 4. Bypass (Non-blocking feature) Requirements . . . . . . . . . . 8 50 4.1 Bypassable entities . . . . . . . . . . . . . . . . . . . . . 9 51 4.2 System requirements . . . . . . . . . . . . . . . . . . . . . 9 52 4.3 Processor requirements . . . . . . . . . . . . . . . . . . . . 10 53 4.4 Callout server requirements . . . . . . . . . . . . . . . . . 10 54 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 11 55 6. Compliance Considerations . . . . . . . . . . . . . . . . . . 12 56 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 58 8.1 Tracing security considerations . . . . . . . . . . . . . . . 14 59 8.2 Bypass security considerations . . . . . . . . . . . . . . . . 15 60 Normative References . . . . . . . . . . . . . . . . . . . . . 17 61 Informative References . . . . . . . . . . . . . . . . . . . . 18 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 63 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 64 Intellectual Property and Copyright Statements . . . . . . . . 20 66 1. Introduction 68 The Open Pluggable Edge Services (OPES) architecture [1] enables 69 cooperative application services (OPES services) between a data 70 provider, a data consumer, and zero or more OPES processors. The 71 application services under consideration analyze and possibly 72 transform application-level messages exchanged between the data 73 provider and the data consumer. 75 This work specifies OPES tracing and bypass functionality. The 76 architecture document [1] requires that tracing is supported in-band. 77 This design goal limits the type of application protocols that OPES 78 can support. The details of what a trace record can convey are also 79 dependent on the choice of the application level protocol. For these 80 reasons, this work only documents requirements for OPES entities that 81 are needed to support traces and bypass functionality. The task of 82 encoding tracing and bypass features is application protocol 83 specific. Separate documents will address HTTP and other protocols. 85 The architecture does not prevent implementers from developing 86 out-of-band protocols and techniques to address tracing and bypass. 87 Such protocols are out of scope of the current work. 89 1.1 Terminology 91 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [2]. When 94 used with the normative meanings, these keywords will be all 95 uppercase. Occurrences of these words in lowercase comprise normal 96 prose usage, with no normative implications. 98 2. OPES System 100 This sections provides a definition of OPES System. This is needed in 101 order to define what is traceable (or bypassable) in an OPES Flow. 103 Definition: An OPES System is a set of all OPES entities authorized 104 by either the data provider or the data consumer application to 105 process a given application message. 107 The nature of the authorization agreement determines if authority 108 delegation is transitive (meaning an authorized entity is authorized 109 to include other entities). 111 If specific authority agreements allow for re-delegation, an OPES 112 system can be formed by induction. In this case, an OPES system 113 starts with entities directly authorized by a data provider (or a 114 data consumer) application. The OPES system then includes any OPES 115 entity authorized by an entity that is already in the OPES system. 116 The authority delegation is always viewed in the context of a given 117 application message. 119 An OPES System is defined on an application message basis. Having an 120 authority to process a message does not imply being involved in 121 message processing. Thus, some OPES system members may not 122 participate in processing of a message. Similarly, some members may 123 process the same message several times. 125 The above definition implies that there can be no more than two OPES 126 systems [Client-side and server-side OPES systems can process the 127 same message at the same time] processing the same message at a given 128 time. This is based on the assumption that there is a single data 129 provider and a single data consumer as far as a given application 130 message is concerned. 132 For example, consider a Content Delivery Network (CDN) delivering an 133 image on behalf of a busy web site. OPES processors and services that 134 the CDN uses to adapt and deliver the image comprise an OPES System. 135 In a more complex example, an OPES System would contain third party 136 OPES entities that the CDN engages to perform adaptations (e.g., to 137 adjust image quality). 139 3. Tracing Requirements 141 The definition of OPES trace and tracing are given next. 143 OPES trace: application message information about OPES entities 144 that adapted the message. 146 OPES tracing: the process of creating, manipulating, or 147 interpreting an OPES trace. 149 Note that the above trace definition assumes in-band tracing. This 150 dependency can be removed if desired. Tracing is performed on per 151 message basis. Trace format is dependent on the application protocol 152 that is being adapted. A traceable entity can appear multiple times 153 in a trace (for example, every time it acts on a message). 155 3.1 Traceable entities 157 This section focuses on identifying traceable entities in an OPES 158 Flow. 160 Tracing information provides an "end" with information about OPES 161 entities that adapted the data. There are two distinct uses of OPES 162 traces. First, a trace enables an "end" to detect the presence of 163 OPES System. Such "end" should be able to see a trace entry, but does 164 not need to be able to interpret it beyond identification of the OPES 165 System and location of certain required OPES-related disclosures (see 166 Section 3.2). 168 Second, the OPES System administrator is expected to be able to 169 interpret the contents of an OPES trace. The trace can be relayed to 170 the administrator by an "end" without interpretation, as opaque data 171 (e.g., a TCP packet or an HTTP message snapshot). The administrator 172 can use the trace information to identify the participating OPES 173 entities. The administrator can use the trace to identify the applied 174 adaptation services along with other message-specific information. 176 Since the administrators of various OPES Systems can have various 177 ways of looking into tracing, they require the freedom in what to put 178 in trace records and how to format them. 180 At the implementation level, for a given trace, an OPES entity 181 involved in handling the corresponding application message is 182 traceable or traced if information about it appears in that trace. 183 This work does not specify any order to that information. The order 184 of information in a trace can be OPES System specific or can be 185 defined by application bindings documents. 187 OPES entities have different levels of traceability requirements. 188 Specifically, 190 o An OPES System MUST add its entry to the trace. 192 o An OPES processor SHOULD add its entry to the trace. 194 o An OPES service MAY add its entry to the trace. 196 o An OPES entity MAY delegate addition of its trace entry to another 197 OPES entity. For example, an OPES System can have a dedicated OPES 198 processor for adding System entries; an OPES processor can use a 199 callout service to manage all OPES trace manipulations (since such 200 manipulations are OPES adaptations). 202 In an OPES context, a good tracing approach is similar to a trouble 203 ticket ready for submission to a known address. The address is 204 printed on the ticket. The trace in itself is not necessarily a 205 detailed description of what has happened. It is the responsibility 206 of the operator to decode trace details and to resolve the problems. 208 3.2 System requirements 210 The following requirements document actions when forming an OPES 211 System trace entry: 213 o OPES system MUST include its unique identification in its trace 214 entry. Here, uniqueness scope is all OPES Systems that may adapt 215 the message being traced. 217 o An OPES System MUST define its impact on inter- and intra-document 218 reference validity. 220 o An OPES System MUST include information about its privacy policy, 221 including identity of the party responsible for setting and 222 enforcing the policy. 224 o An OPES System SHOULD include information that identifies, to the 225 technical contact, the OPES processors involved in processing the 226 message. 228 o When providing required information, an OPES System MAY use a 229 single URI to identify a resource containing several required 230 items. For example, an OPES System can point to a single web page 231 with a reference to System privacy policy and technical contact 232 information. 234 This specification does not define the meaning of the terms privacy 235 policy, policy enforcement, or reference validity or technical 236 contact and contains no requirements regarding encoding, language, 237 format, or any other aspects of that information. For example, a URI 238 used for an OPES System trace entry may look like "http:// 239 www.examplecompany.com/opes/?client=example.com" where the identified 240 web page is dynamically generated and contains the all OPES System 241 information required above. 243 3.3 Processor requirements 245 The following requirements document actions when forming an OPES 246 System trace entry: 248 o OPES processor SHOULD add its unique identification to the trace. 249 Here, uniqueness scope is the OPES System containing the 250 processor. 252 3.4 Callout server requirements 254 In an OPES system, it is the task of an OPES processor to add trace 255 records to application messages. The OPES System administrator 256 decides if and under what conditions callout servers may add trace 257 information to application messages. 259 4. Bypass (Non-blocking feature) Requirements 261 IAB recommendation (3.3) [4] requires that the OPES architecture does 262 not prevent a data consumer application from retrieving non-OPES 263 version of content from a data provider application, provided that 264 the non-OPES content exists. IAB recommendation (3.3) suggests that 265 the Non-blocking feature (bypass) be used to bypass faulty OPES 266 intermediaries (once they have been identified, by some method). 268 In addressing IAB consideration (3.3), one need to specify what 269 constitutes non-OPES content. In this work the definition of 270 "non-OPES" content is provider dependent. In some cases, the 271 availability of "non-OPES" content can be a function of the internal 272 policy of a given organization that has contracted the services of an 273 OPES provider. For example, Company A has as contract with an OPES 274 provider to perform virus checking on all e-mail attachments. An 275 employee X of Company A can issue a non-blocking request for the 276 virus scanning service. The request could be ignored by the OPES 277 provider since it contradicts its agreement with Company A. 279 The availability of non-OPES content can be a function of content 280 providers (or consumers or both) policy and deployment scenarios [3]. 281 For this reason, this work does not attempt to define what is an OPES 282 content as opposed to non-OPES content. The meaning of OPES versus 283 non-OPES content is assumed to be determined through various 284 agreements between the OPES provider, data provider and/or data 285 consumer. The agreement determines what OPES services can be bypassed 286 and in what order (if applicable). 288 This specification documents bypassing of an OPES service or a group 289 of services identified by a URI. In this context, to "bypass the 290 service" for a given application message in an OPES Flow means to 291 "not invoke the service" for that application message. A bypass URI 292 that identifies an OPES system (processor) matches all services 293 attached to that OPES system (processor). However, bypassing of OPES 294 processors and OPES Systems themselves requires non-OPES mechanisms 295 and is out of this specification scope. A bypass request an 296 instruction to bypass, usually embedded in an application message. 298 The current specification does not provide for a good mechanism that 299 allow and "end" to specify to "bypass this service but only if it is 300 a part of that OPES system" or "bypass all services of that OPES 301 system but not of this OPES system". Furthermore, if an OPES 302 processor does not know for sure that a bypass URI does not match its 303 service, it must bypass that service. 305 If no non-OPES content is available without the specified service, 306 the bypass request for that service must be ignored. This design 307 implies that it may not be possible to detect non-OPES content 308 existence or to detect violations of bypass rules in the environments 309 where the tester does not know whether non-OPES content exists. This 310 design assumes that most bypass requests are intended for situations 311 where serving undesirable OPES content is better than serving an 312 error message that no preferred non-OPES content exists. 314 4.1 Bypassable entities 316 In this work, the focus is on developing a bypass feature that allow 317 a user to instruct the OPES System to bypass some or all of its 318 services. The collection of OPES services that can be bypassed is a 319 function of the agreement of the OPES provider with either (or both) 320 the content provider or the content consumer applications. In the 321 general case, a bypass request is viewed as a bypass instruction that 322 contains a URI that identifies an OPES entity or a group of OPES 323 entities that perform a service (or services) to be bypassed. An 324 instruction may contain more than one such URI. A special wildcard 325 identifier can be used to represent all possible URIs. 327 In an OPES Flow, a bypass request is processed by each involved OPES 328 processor. This means that an OPES processor examines the bypass 329 instruction and if non-OPES content is available, the processor then 330 bypasses the indicated services. The request is then forwarded to the 331 next OPES processor in the OPES Flow. The next OPES processor would 332 then handle all bypass requests, regardless of the previous processor 333 actions. The processing chain continues throughout the whole 334 processors that are involved in the OPES Flow. 336 4.2 System requirements 338 In an OPES System bypass requests are generally client centric 339 (originated by the data consumer application) and go in the opposite 340 direction of tracing requests. This work requires that the bypass 341 feature be performed in-band as an extension to an application 342 specific protocol. Non-OPES entities should be able to safely ignore 343 these extensions. The work does not prevent OPES Systems from 344 developing their own out of band protocols. 346 The following requirements apply for bypass feature as related to an 347 OPES System (the availability of a non-OPES content is a 348 precondition) : 350 o An OPES System MUST support a bypass feature. This means that the 351 OPES System bypasses services whose URIs are identified by an OPES 352 "end". 354 o An OPES System MUST provide OPES version of the content if 355 non-OPES version is not available. 357 In order to facilitate the debugging (or data consumer user 358 experience) of the bypass feature in an OPES System, it would be 359 beneficial if non-bypassed entities include information related to 360 why they ignored the bypass instruction. It is important to note that 361 in some cases the tracing facility itself may be broken and the whole 362 OPES System (or part) may need to be bypassed through the issue of a 363 bypass instruction. 365 4.3 Processor requirements 367 Bypass requirements for OPES processors are (the availability of a 368 non-OPES content is a precondition): 370 o OPES processor SHOULD be able to interpret and process a bypass 371 instruction. This requirement applies to all bypass instructions, 372 including those that identify unknown-to-recipient services. 374 o OPES processors MUST forward bypass request to the next 375 application hop provided that the next hop speaks application 376 protocol with OPES bypass support. 378 o OPES processor SHOULD be able to bypass it's service(s) execution. 380 OPES processors that know how to process and interpret a bypass 381 instruction have the following requirements: 383 o The recipient of a bypass instruction with a URI that does not 384 identify any known-to-recipient OPES entity MUST treat that URI as 385 a wildcard identifier (meaning bypass all applicable services). 387 4.4 Callout server requirements 389 In an OPES system, it is the task of an OPES processor to process 390 bypass requests. The OPES System administrator decides if and under 391 what conditions callout servers process bypass requests. 393 5. Protocol Binding 395 The task of encoding tracing and bypass features is application 396 protocol specific. Separate documents will address HTTP and other 397 protocols. These documents must address the ordering of trace 398 information if needed. 400 6. Compliance Considerations 402 This specification defines compliance for the following compliance 403 subjects: OPES System, processors, entities and callout servers. 405 A compliance subject is compliant if it satisfies all applicable 406 "MUST" and "SHOULD" level requirements. By definition, to satisfy a 407 "MUST" level requirement means to act as prescribed by the 408 requirement; to satisfy a "SHOULD" level requirement means to either 409 act as prescribed by the requirement or have a reason to act 410 differently. A requirement is applicable to the subject if it 411 instructs (addresses) the subject. 413 Informally, compliance with this draft means that there are no known 414 "MUST" violations, and all "SHOULD" violations are conscious. In 415 other words, a "SHOULD" means "MUST satisfy or MUST have a reason to 416 violate". It is expected that compliance claims are accompanied by a 417 list of unsupported SHOULDs (if any), in an appropriate format, 418 explaining why preferred behavior was not chosen. 420 Only normative parts of this specification affect compliance. 421 Normative parts are: parts explicitly marked using the word 422 "normative", definitions, and phrases containing unquoted capitalized 423 keywords from [RFC2119]. Consequently, examples and illustrations are 424 not normative. 426 7. IANA considerations 428 This specification contains no IANA considerations. Application 429 bindings MAY contain application-specific IANA considerations. 431 8. Security Considerations 433 The security considerations for OPES are documented in [8]. This 434 document is a requirement document for tracing and bypass feature. 435 The requirements that are stated in this document can be used to 436 extend an application level protocol to support these features. As 437 such, the work has security precautions. 439 8.1 Tracing security considerations 441 The tracing facility for OPES architecture is implemented as a 442 protocol extension. Inadequate implementations of the tracing 443 facility may defeat safeguards built into the OPES architecture. The 444 tracing facility by itself can become a target of malicious attacks 445 or used to lunch attacks on an OPES System. 447 Threats caused by or against the tracing facility can be viewed as 448 threats at the application level in an OPES Flow. In this case, the 449 threats can affect the data consumer and the data provider 450 application. 452 Since tracing information is a protocol extension, these traces can 453 be injected in the data flow by non-OPES entities. In this case, 454 there are risks that non-OPES entities can be compromised in a 455 fashion that threat the overall integrity and effectiveness of an 456 OPES System. For example, a non-OPES proxy can add fake tracing 457 information into a trace. This can be done in the form of wrong, or 458 unwanted, or non existent services. A non-OPES entity can inject 459 large size traces that may cause buffer overflow in a data consumer 460 application. The same threats can arise from compromised OPES 461 entities. An attacker can control an OPES entity and inject wrong, or 462 very large trace information that can overwhelm an end or the next 463 OPES entity in an OPES flow. Similar threats can result from bad 464 implementations of the tracing facility in trusted OPES entities. 466 Compromised tracing information can be used to launch attacks on an 467 OPES System that give the impression that unwanted content 468 transformation was performed on the data. This can be achieved by 469 inserting wrong entity (such OPES processor) identifiers. A 470 compromised trace can affect the overall message integrity structure. 471 This can affect entities that use message header information to 472 perform services such as accounting, load balancing, or 473 reference-based services. 475 Compromised trace information can be used to launch DoS attacks that 476 can overwhelm a data consumer application or an OPES entity in an 477 OPES Flow. Inserting wrong tracing information can complicates the 478 debugging tasks performed by system administrator during trouble 479 shooting of OPES System behavior. 481 As a precaution, OPES entities ought to be capable of verifying that 482 the inserted traces are performed by legal OPES entities. This can be 483 done as part of the authorization and authentication face. Policy can 484 be used to indicate what trace information can be expected from a 485 peer entity. Other application level related security concerns can be 486 found in [8]. 488 8.2 Bypass security considerations 490 The bypass facility for OPES architecture is implemented as a 491 protocol extension. Inadequate implementations of the bypass facility 492 may defeat safeguards built into the OPES architecture. The bypass 493 facility by itself can become a target of malicious attacks or used 494 to lunch attacks on an OPES System. 496 Threats caused by or against the bypass facility can be viewed as 497 threats at the application level in an OPES Flow. In this case, the 498 threats can affect the data consumer and the data provider 499 application. 501 There are risks for the OPES System by non-OPES entities, whereby, 502 these entities can insert bypass instructions into the OPES Flow. The 503 threat can come from compromised non-OPES entities. The threat might 504 affect the overall integrity and effectiveness of an OPES System. For 505 example, a non-OPES proxy can add bypass instruction to bypass 506 legitimate OPES entities. The attack might result in overwhelming the 507 original content provider servers, since the attack essentially 508 bypass any load balancing techniques. In addition, such an attack is 509 also equivalent to a DoS attack, whereby, a legitimate data consumer 510 application may not be able to access some content from a content 511 provider or its OPES version. 513 Since an OPES Flow may include non-OPES entities, it is susceptible 514 to man-in-the-middle attacks, whereby an intruder may inject bypass 515 instructions into the data path. These attacks may affect content 516 availability or disturb load balancing techniques in the network. 518 The above threats can also arise by compromised OPES entities. An 519 intruder can compromise an OPES entities and then use 520 man-in-the-middle techniques to disturb content availability to a 521 data consumer application or overload a content provider server 522 (essentially, some form of a DoS attack). 524 Attackers can use the bypass instruction to affect the overall 525 integrity of the OPES System. The ability to introduce bypass 526 instructions into a data flow may effect the accounting of the OPES 527 System. It may also affect the quality of content that is delivered 528 to the data consumer applications. Similar threats can arise from bad 529 implementations of the bypass facility. 531 Inconsistent or selective bypass is also a threat. Here, one end can 532 try to bypass a subset of OPES entities so that the resulting content 533 is malformed and crashes or compromises entities that process that 534 content (and expect that content to be complete and valid). Such 535 exceptions are often not tested because implementers do not expect a 536 vital service to disappear from the processing loop. 538 Other threats can arise from configuring access control policies for 539 OPES entities. It is possible that systems implementing access 540 controls via OPES entities may be incorrectly configured to honor 541 bypass and, hence, give unauthorized access to intruders. 543 Tap bypass can also be a threat. This is because systems implementing 544 wiretaps via OPES entities may be incorrectly configured to honor 545 bypass and, hence, ignore (leave undetected) traffic with bypass 546 instructions that should have been tapped or logged. It is also 547 possible for one end to bypass services such as virus scanning at the 548 receiving end. This threat can be used by hackers to inject viruses 549 throughout the network. 551 Other application level related security concerns can be found in 552 [8]. 554 Normative References 556 [1] A. Barbir et al., "An Architecture for Open Pluggable Edge 557 Services (OPES)", Internet-Draft http://www.ietf.org/ 558 internet-drafts/draft-ietf-opes-architecture-04, December 2002. 560 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 561 Levels", RFC 2119, March 1997. 563 Informative References 565 [3] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", 566 Internet-Draft http://www.ietf.org/internet-drafts/ 567 draft-ietf-opes-scenarios-01.txt, August 2002. 569 [4] Floyd, S. and L. Daigle, "IAB Architectural and Policy 570 Considerations for Open Pluggable Edge Services", RFC 3238, 571 January 2002. 573 [5] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 574 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 575 HTTP/1.1", RFC 2616, June 1999. 577 [6] A. Barbir et al., "Policy, Authorization and Enforcement 578 Requirements of OPES", Internet-Draft http://www.ietf.org/ 579 internet-drafts/draft-ietf-opes-authorization-02.txt, February 580 2003. 582 [7] Rousskov, A. et al, "HTTP adaptation with OPES", Internet-Draft 583 http://www.ietf.org/internet-drafts/draft-ietf-opes-http-01.txt, 584 October 2003. 586 [8] A. Barbir et al., "Security Threats and Risks for Open Pluggable 587 Edge Services", Internet-Draft http://www.ietf.org/ 588 internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. 590 [9] A. Barbir et al., "OPES Treatment of IAB Considerations", 591 Internet-Draft http://www.ietf.org/internet-drafts/ 592 draft-ietf-opes-iab-03.txt, October 2003. 594 Author's Address 596 Abbie Barbir 597 Nortel Networks 598 3500 Carling Avenue 599 Nepean, Ontario K2H 8E9 600 Canada 602 Phone: +1 613 763 5229 603 EMail: abbieb@nortelnetworks.com 605 Appendix A. Acknowledgements 607 Several people has contributed to this work. Many thanks to: Alex 608 Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin 609 Stecher, Marshall Rose and Reinaldo Penno. 611 Intellectual Property Statement 613 The IETF takes no position regarding the validity or scope of any 614 intellectual property or other rights that might be claimed to 615 pertain to the implementation or use of the technology described in 616 this document or the extent to which any license under such rights 617 might or might not be available; neither does it represent that it 618 has made any effort to identify any such rights. Information on the 619 IETF's procedures with respect to rights in standards-track and 620 standards-related documentation can be found in BCP-11. Copies of 621 claims of rights made available for publication and any assurances of 622 licenses to be made available, or the result of an attempt made to 623 obtain a general license or permission for the use of such 624 proprietary rights by implementors or users of this specification can 625 be obtained from the IETF Secretariat. 627 The IETF invites any interested party to bring to its attention any 628 copyrights, patents or patent applications, or other proprietary 629 rights which may cover technology that may be required to practice 630 this standard. Please address the information to the IETF Executive 631 Director. 633 Full Copyright Statement 635 Copyright (C) The Internet Society (2003). All Rights Reserved. 637 This document and translations of it may be copied and furnished to 638 others, and derivative works that comment on or otherwise explain it 639 or assist in its implementation may be prepared, copied, published 640 and distributed, in whole or in part, without restriction of any 641 kind, provided that the above copyright notice and this paragraph are 642 included on all such copies and derivative works. However, this 643 document itself may not be modified in any way, such as by removing 644 the copyright notice or references to the Internet Society or other 645 Internet organizations, except as needed for the purpose of 646 developing Internet standards in which case the procedures for 647 copyrights defined in the Internet Standards process must be 648 followed, or as required to translate it into languages other than 649 English. 651 The limited permissions granted above are perpetual and will not be 652 revoked by the Internet Society or its successors or assignees. 654 This document and the information contained herein is provided on an 655 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 656 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 657 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 658 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 659 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 661 Acknowledgment 663 Funding for the RFC Editor function is currently provided by the 664 Internet Society.