RFC 3897

Open Pluggable Edge Services (OPES) Entities and End Points Communication

📅 published September 2004, from ietf

RFC 3897: Open Pluggable Edge Services (OPES) Entities and End Points Communication ✨

Author: A. Barbir (Nortel Networks) 🎀 Category: Informational (this is just for info, not a standard!) 📚 Date: September 2004 📅

Okay bestie, this one is all about tracing and bypass requirements for OPES (Open Pluggable Edge Services). It's basically the rules for how OPES entities leave their footprints in a message and how things can skip right past them. 🦋

Status of this Memo

This memo is information for the Internet community. It is not a standard of any kind, and anyone can read it. 🌸

Copyright (C) The Internet Society (2004). 💜

Abstract

This memo writes down the tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). ✨

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . .  2
   2.  OPES System  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  Tracing Requirements . . . . . . . . . . . . . . . . . . . . .  3
       3.1.  Traceable entities . . . . . . . . . . . . . . . . . . .  3
       3.2.  System requirements  . . . . . . . . . . . . . . . . . .  5
       3.3.  Processor requirements . . . . . . . . . . . . . . . . .  5
       3.4.  Callout server requirements  . . . . . . . . . . . . . .  5
   4.  Bypass (Non-blocking feature) Requirements . . . . . . . . . .  6
       4.1.  Bypassable entities  . . . . . . . . . . . . . . . . . .  7
       4.2.  System requirements  . . . . . . . . . . . . . . . . . .  8
       4.3.  Processor requirements . . . . . . . . . . . . . . . . .  8
       4.4.  Callout server requirements  . . . . . . . . . . . . . .  9
   5.  Protocol Binding . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Compliance Considerations  . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
       8.1.  Tracing security considerations  . . . . . . . . . . . . 10
       8.2.  Bypass security considerations . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       9.1.  Normative References . . . . . . . . . . . . . . . . . . 12
       9.2.  Informative References . . . . . . . . . . . . . . . . . 13
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14

1. Introduction 🌈

Okay so the OPES architecture [1] is what makes cooperative application services (OPES services) possible. These services sit between a data provider, a data consumer, and zero or more OPES processors. The fun part? They analyze and sometimes transform the application-level messages that go back and forth between the provider and the consumer. 💅

This doc specifies the OPES tracing and bypass stuff. The architecture [1] says tracing has to happen in-band, which is a big vibe check because it limits which application protocols OPES can even work with. What a trace record can say also depends on which application-level protocol you're using. So this work only covers the requirements for OPES entities that are needed for tracing and bypass. Actually encoding those features is up to each application protocol, and separate documents will handle HTTP and the others. 🦋

The architecture doesn't stop anyone from building out-of-band protocols and techniques for tracing and bypass. Those are out of scope for this work, though. 🙈

1.1. Terminology

Here's the keyword situation: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way BCP 14, RFC 2119 [2] describes. When they're used with those normative meanings, they're written in all caps. If the same words show up in lowercase, that's just regular prose with no normative weight. 🫶

2. OPES System 🎀

This section defines what an OPES System is, and you need that to know what's traceable (or bypassable) in an OPES Flow. 💖

Definition: An OPES System is the set of all OPES entities that the data provider or the data consumer application has authorized to process a given application message. 👑

Whether authority can be passed along depends on the authorization agreement. If it's transitive, that means an authorized entity is allowed to bring other entities in. 🧚

If the agreements do allow re-delegation, then an OPES system can be built up inductively. It starts with the entities that a data provider (or a data consumer) application authorized directly. Then it grows to include any OPES entity that was authorized by someone already in the system. Delegation always gets looked at in the context of one specific application message. ✨

An OPES System is defined per application message. Being authorized to process a message doesn't mean you actually show up and process it. So some OPES system members might never touch a given message, and others might process the same message several times. 🌸

Because of the definition above, there can be no more than two OPES systems processing the same message at a given time. That's because you're assuming there's exactly one data provider and one data consumer for that message. [Client-side and server-side OPES systems can process the same message at the same time.] 🔥

Here's an example. Picture a Content Delivery Network (CDN) delivering an image for a super busy website. The OPES processors and services the CDN uses to adapt and deliver that image make up an OPES System. A more complex example: the OPES System could also include third-party OPES entities that the CDN hires to do adaptations, like tweaking the image quality. 📸

3. Tracing Requirements 🍓

Here are the definitions for OPES trace and tracing:

OPES trace: application message information about the OPES entities that adapted the message. 🔍 OPES tracing: the process of creating, manipulating, or interpreting an OPES trace. 🛠️

Heads up, the trace definition assumes in-band tracing. You can drop that dependency if you want to. Tracing happens on a per-message basis, and the trace format depends on the application protocol being adapted. A traceable entity can show up multiple times in one trace (say, every time it acts on a message). 🦋

3.1. Traceable entities 💜

This section is all about spotting the traceable entities in an OPES Flow. 🕵️‍♀️

Tracing info gives an "end" the lowdown on which OPES entities adapted the data. There are two separate uses for OPES traces, and this is where it gets good:

First, a trace lets an "end" detect that an OPES System is there. That "end" should be able to see a trace entry, but it doesn't have to actually understand it beyond identifying the OPES System and finding certain required OPES-related disclosures (see Section 3.2). 👀

Second, the OPES System administrator is expected to be able to interpret what's in an OPES trace. An "end" can pass the trace along to the administrator without reading it, treating it as opaque data (for example, a TCP packet or an HTTP message snapshot). The administrator can use the trace to figure out which OPES entities took part, and to see which adaptation services were applied along with other message-specific info. 🧐

Different OPES Systems might look at tracing in totally different ways, so they need the freedom to decide what goes into trace records and how those records are formatted. 🎨

At the implementation level, an OPES entity that handled the corresponding application message is "traceable" or "traced" for a given trace if info about it shows up in that trace. This work doesn't set any order for that info. The order inside a trace can be specific to each OPES System, or it can be defined by application binding documents. 📋

OPES entities don't all have the same traceability requirements. Here's the breakdown:

  • An OPES System MUST add its entry to the trace.
  • An OPES processor SHOULD add its entry to the trace.
  • An OPES service MAY add its entry to the trace.
  • An OPES entity MAY delegate adding its trace entry to another OPES entity. For example, an OPES System can have a dedicated OPES processor just for adding System entries. An OPES processor can also use a callout service to handle all the OPES trace manipulations, since those manipulations count as OPES adaptations. 🌟

In the OPES world, a good tracing approach is like a trouble ticket that's ready to submit to a known address. The address is printed right on the ticket. The trace itself isn't necessarily a detailed play-by-play of what happened. It's on the operator to decode the trace details and actually fix the problems. 🎫

3.2. System requirements 🫧

These requirements cover what an OPES System has to do when it forms its trace entry:

  • An OPES System MUST include its unique identification in its trace entry. The uniqueness scope here is all OPES Systems that might adapt the message being traced.
  • An OPES System MUST define its impact on inter- and intra-document reference validity.
  • An OPES System MUST include information about its privacy policy, including the identity of the party responsible for setting and enforcing that policy.
  • An OPES System SHOULD include information that identifies, for the technical contact, the OPES processors involved in processing the message.
  • When it's providing the required information, an OPES System MAY use a single URI to point to a resource that holds several of the required items. For example, an OPES System can point to a single web page that references its privacy policy and its technical contact info. 🔗

Quick note: this spec doesn't define what privacy policy, policy enforcement, reference validity, or technical contact actually mean. It also has no requirements about encoding, language, format, or any other aspects of that info. For example, a URI used for an OPES System trace entry might look like "http://www.examplecompany.com/opes/?client=example.com", where the web page it points to is dynamically generated and contains all the OPES System information required above. 💻

3.3. Processor requirements 🌷

These requirements cover what an OPES processor has to do when it forms an OPES System trace entry:

  • An OPES processor SHOULD add its unique identification to the trace. The uniqueness scope is the OPES System that contains the processor. 🧩

3.4. Callout server requirements 🍭

In an OPES system, it's the job of an OPES processor to add trace records to application messages. The OPES System administrator decides whether callout servers can add trace info to application messages, and if so, under what conditions. 👑🎀

4. Bypass (Non-blocking feature) Requirements ✨

Okay bestie, bypass is where things get spicy 🌶️. IAB recommendation (3.3) [6] says the OPES architecture must not stop a data consumer application from grabbing a non-OPES version of content from a data provider application, as long as that non-OPES content actually exists 🫶. The same recommendation suggests using the Non-blocking feature (bypass) to skip faulty OPES intermediaries, once somebody has figured out which ones are faulty (by some method, not specified here) 🔍.

To deal with IAB consideration (3.3), we need to decide what counts as non-OPES content, and honestly? That's up to the provider 💅. In some cases, whether non-OPES content is available depends on the internal policy of the organization that hired an OPES provider. For example, Company A has a contract with an OPES provider to virus-check every e-mail attachment. If an employee X of Company A sends a non-blocking request for that virus scanning service, the OPES provider could just ignore it, because it goes against the agreement with Company A 🙅‍♀️.

Whether non-OPES content is available can also depend on the policies of content providers (or consumers, or both) and on how things are deployed [5]. That's why this work doesn't try to pin down what OPES content is versus non-OPES content 🤷‍♀️. Those meanings are assumed to come from agreements between the OPES provider, the data provider and/or the data consumer. The agreement decides which OPES services can be bypassed, and in what order if that matters 📜.

This specification covers bypassing an OPES service, or a group of services, identified by a URI 🎀. In this context, "bypass the service" for a given application message in an OPES Flow means "don't invoke the service" for that message. A bypass URI that identifies an OPES system (processor) matches all the services attached to that OPES system (processor) 🧚. Bypassing OPES processors and OPES Systems themselves needs non-OPES mechanisms, so it's outside the scope of this spec 🙈. A bypass request is an instruction to bypass, usually embedded in an application message 💌.

Right now, the spec doesn't have a good mechanism that lets an "end" say "bypass this service, but only if it's part of that OPES system," or "bypass all services of that OPES system, but not the ones in this OPES system" 😭. Also, if an OPES processor isn't sure whether a bypass URI doesn't match its service, it must bypass that service 🫣.

If there's no non-OPES content available without the specified service, the bypass request for that service must be ignored 💀. This means it might not be possible to detect whether non-OPES content exists, or to detect violations of bypass rules, in environments where the tester doesn't know if non-OPES content is there. The reasoning is that most bypass requests are meant for situations where serving undesirable OPES content is better than serving an error message saying no preferred non-OPES content exists 🌸.

Bypass is to malfunctioning OPES services what the HTTP "reload" request is to malfunctioning HTTP caches 🔄. Its main job is getting usable content when services are failing, not explaining to the content consumer what's going on. For that, OPES trace is the tool to use 🔎.

This work defines a "bypass service if possible" feature, but other related bypass features could be built into OPES and/or into the application protocols being adapted 🦋. For example, there could be a "bypass service or generate an error" feature, or a "bypass OPES entity or generate an error" feature. Those would be handy for debugging broken OPES systems, and they might get defined in other OPES specifications 🛠️. This work focuses on a user-level bypass feature that handles the direct IAB concerns 💖.

4.1. Bypassable entities

Here the focus is on a bypass feature that lets a user tell the OPES System to bypass some or all of its services 🦄. Which OPES services can be bypassed depends on what the OPES provider has agreed to with the content provider, the content consumer applications, or both 🤝. In the general case, a bypass request is a bypass instruction containing a URI that identifies an OPES entity, or a group of OPES entities, that performs the service (or services) to be bypassed 🎯. One instruction can contain more than one such URI 🍓. There's also a special wildcard identifier that stands in for all possible URIs 🌈.

In an OPES Flow, every OPES processor involved handles the bypass request 💅. Each processor looks at the bypass instruction, and if non-OPES content is available, it bypasses the services it was told to bypass. Then the request gets passed along to the next OPES processor in the OPES Flow 🏃‍♀️. That next processor handles all bypass requests on its own, no matter what the previous processors did 🙌. This chain keeps going through every processor involved in the OPES Flow ⭐.

4.2. System requirements

In an OPES System, bypass requests usually come from the client side (the data consumer application) and travel the opposite way from tracing requests 🔁. This work says the bypass feature must be done in-band, as an extension to an application-specific protocol 📦. Non-OPES entities should be able to safely ignore these extensions 🫶. The work doesn't stop OPES Systems from building their own out-of-band protocols, though 🧚‍♀️.

These are the requirements for the bypass feature in an OPES System. Keep in mind that the availability of non-OPES content is a precondition here 👑:

  • An OPES System MUST support a bypass feature. This means that the OPES System bypasses services whose URIs are identified by an OPES "end". 🎀
  • An OPES System MUST provide the OPES version of the content if the non-OPES version is not available. 💖

To make debugging (or the data consumer's experience) of the bypass feature easier in an OPES System, it would be helpful if non-bypassed entities included information about why they ignored the bypass instruction 🔍. Also, it's important to note that the tracing facility itself might be broken. In that case, the whole OPES System (or part of it) may need to be bypassed by issuing a bypass instruction 😬.

4.3. Processor requirements

These are the bypass requirements for OPES processors. The availability of non-OPES content is still a precondition 💅:

  • An OPES processor SHOULD be able to interpret and process a bypass instruction. This applies to all bypass instructions, including the ones that identify services unknown to the recipient. 🧠
  • An OPES processor MUST forward the bypass request to the next application hop, provided that the next hop speaks an application protocol with OPES bypass support. 🏃‍♀️
  • An OPES processor SHOULD be able to bypass its own service(s) execution. 🌸

For OPES processors that know how to process and interpret a bypass instruction, there's one more requirement 🔥:

  • The recipient of a bypass instruction with a URI that doesn't identify any entity known to the recipient MUST treat that URI as a wildcard identifier (meaning bypass all applicable services). 🌟

4.4. Callout server requirements

In an OPES system, processing bypass requests is the job of an OPES processor 💁‍♀️. The OPES System administrator decides whether callout servers process bypass requests, and under what conditions 👑.

5. Protocol Binding 🧩

Encoding the tracing and bypass features is specific to each application protocol 🦋. Separate documents will cover HTTP and other protocols 📚. Those documents must address the ordering of trace information as needed 🔢.

6. Compliance Considerations 📋

This specification defines compliance for these 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, satisfying a "MUST" level requirement means acting as the requirement prescribes. Satisfying a "SHOULD" level requirement means either acting as the requirement prescribes or having a reason to act differently 🧐. A requirement applies to the subject if it instructs (addresses) that subject 🎯.

Informally, compliance with this document means there are no known "MUST" violations, and all "SHOULD" violations are deliberate 🫶. In other words, a "SHOULD" means "MUST satisfy or MUST have a reason to violate" 🔁. Compliance claims are expected to come with a list of unsupported SHOULDs (if there are any), in an appropriate format, explaining why the preferred behavior wasn't chosen 📝.

Only the normative parts of this specification affect compliance! Those are: parts explicitly marked with the word "normative," definitions, and phrases containing unquoted capitalized keywords from RFC 2119 [2]. Examples and illustrations are NOT normative, so they don't count toward compliance 🙈.

7. IANA Considerations 🌈

This specification contains no IANA considerations. Application bindings MAY contain application-specific IANA considerations 💖.

8. Security Considerations 🚨

Security considerations for OPES are documented in [4], and policy and authorization issues are documented in [3]. It is recommended that designers consult these documents before reading this section 📚👀.

This document is a requirement document for the tracing and bypass features. The requirements stated here can be used to extend an application-level protocol to support these features. Because of that, this work comes with security precautions, and you should take them seriously 😭🔐.

8.1. Tracing security considerations 🔍✨

okay so the tracing facility for the OPES architecture is built as a protocol extension 🧵, and if it's implemented badly it can totally undo the safeguards the OPES architecture put in place 😭. The tracing facility on its own can also become a target for malicious attacks, or get used to launch attacks on an OPES System 💀.

Threats caused by or against the tracing facility count as application-level threats in an OPES Flow 🎀. That means both the data consumer and the data provider application can feel the hit.

Since tracing info is a protocol extension, non-OPES entities can inject traces into the data flow too 👀. Those non-OPES entities could get compromised in a way that messes with the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy could add fake tracing info, listing services that are wrong, unwanted, or don't exist at all 🙅‍♀️. A non-OPES entity could also inject really large traces that overflow a buffer in a data consumer application 💥. The same stuff can happen with compromised OPES entities. An attacker who controls an OPES entity can inject wrong or very large trace info that overwhelms an end or the next OPES entity in an OPES flow 😩. Bad implementations of the tracing facility in trusted OPES entities can cause similar trouble 🫠.

Compromised tracing info can also be used to make it look like unwanted content transformation happened to the data 🎭. This works by inserting wrong entity identifiers, such as the ID of an OPES processor. A compromised trace can mess with the overall message integrity structure, and that affects anything using message header info for accounting, load balancing, or reference-based services 📊.

Compromised trace info can also be used for DoS attacks that overwhelm a data consumer application or an OPES entity in an OPES Flow 🚨. And inserting wrong tracing info makes debugging harder for system administrators troubleshooting OPES System behavior 🔧.

As a precaution, OPES entities ought to be capable of verifying that the inserted traces were done by legit OPES entities 🛡️. This can be handled as part of the authorization and authentication work. Policy can be used to say what trace info to expect from a peer entity 📜. Other application-level security concerns are covered in [4] 💅.

8.2. Bypass security considerations 🙅‍♀️🌸

The bypass facility for the OPES architecture is also a protocol extension 🧵. Inadequate implementations can defeat the safeguards built into the OPES architecture 😤. The bypass facility on its own can become a target for malicious attacks, or get used to launch attacks on an OPES System 💀.

Threats caused by or against the bypass facility count as application-level threats in an OPES Flow 🎀. The data consumer and the data provider application can both be affected.

There are risks for the OPES System from non-OPES entities, which can insert bypass instructions into the OPES Flow 👀. That threat can come from compromised non-OPES entities, and it might affect the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy can add a bypass instruction to skip legitimate OPES entities. That attack might overwhelm the original content provider servers, since it basically gets around any load balancing techniques 😱. It's also equivalent to a DoS attack, because 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's susceptible to man-in-the-middle attacks, where an intruder injects bypass instructions into the data path 🕵️‍♀️. These attacks can affect content availability or disturb load balancing techniques in the network.

The threats above can also come from compromised OPES entities 🫣. An intruder can compromise an OPES entity and then use man-in-the-middle techniques to disturb content availability for a data consumer application, or overload a content provider server. Basically, it's some form of DoS attack.

Attackers can use bypass instructions to affect the overall integrity of the OPES System 📉. Being able to introduce bypass instructions into a data flow can affect the accounting of the OPES System, and it can also affect the quality of content delivered to data consumer applications. Bad implementations of the bypass facility can cause similar threats 😬.

Inconsistent or selective bypass is also a threat 🧩. Here, one end can try to bypass a subset of OPES entities so the resulting content is malformed, and that can crash or compromise entities that process it (and expect the content to be complete and valid). These exceptions often go untested, because implementers don't expect a vital service to disappear from the processing loop 🙈.

Other threats can come from configuring access control policies for OPES entities 🔐. Systems that implement access controls via OPES entities may be misconfigured to honor bypass, which can give unauthorized access to intruders.

Tap bypass can be a threat too 🎧. Systems that implement wiretaps via OPES entities may be misconfigured to honor bypass, so they ignore (and leave undetected) traffic with bypass instructions that should have been tapped or logged. It's also possible for one end to bypass services like virus scanning at the receiving end, and hackers could use that to inject viruses throughout the network 🦠. Following the IETF policy on Wiretapping [7], the OPES communication model does not consider wiretapping requirements. Still, the documented threat is real, not obvious, and OPES technology users operating in wiretapping or similar logging environments should be aware of it 👀💜.

Other application-level security concerns are covered in [4] 💅.

9. References 📚

9.1. Normative References

[1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[3] Barbir, A., Batuner, O., Beck, A., Chan, T., and H. Orman, "Policy, Authorization, and Enforcement Requirements of Open Pluggable Edge Services (OPES)", RFC 3838, August 2004.

[4] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. Orman, "Security Threats and Risks for Open Pluggable Edge Services (OPES)", RFC 3837, August 2004.

9.2. Informative References

[5] Barbir A., Burger, E., Chen, R., McHenry, S., Orman, H., and R. Penno, "Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios", RFC 3752, April 2004.

[6] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.

[7] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.

10. Acknowledgements 🫶

Several people have contributed to this work. Many thanks to: Alex Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin Stecher, Marshall Rose and Reinaldo Penno 🌈💖.

11. Author's Address 💌

Abbie Barbir
Nortel Networks
3500 Carling Avenue
Nepean, Ontario  K2H 8E9
Canada

Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔏

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society ✨

📦 where this page comes from