RFC 3837

Security Threats and Risks for Open Pluggable Edge Services (OPES)

📅 published August 2004, from ietf

RFC 3837: Security Threats and Risks for Open Pluggable Edge Services (OPES) 🎀

Okay bestie, this is RFC 3837 from the Network Working Group 🌸 It's Informational, which means it's a provides information doc and not a standard ✨ It's dated August 2004, and the authors are A. Barbir (Nortel Networks), O. Batuner (independent consultant), B. Srinivas (Nokia), M. Hofmann (Bell Labs/Lucent Technologies), and H. Orman (Purple Streak Development) 👑 It doesn't list any RFC it obsoletes or updates, so it's standing on its own, no cap 💅

Status of this Memo 📜

This memo is here to give information to the Internet community. It is not an Internet standard of any kind, and distribution of it is unlimited 🦋

Copyright (C) The Internet Society (2004).

Abstract 🧚

This doc is all about the security threats that come with Open Pluggable Edge Services (OPES) 😭 It looks at how those threats affect the underlying architecture, and the main goal is threat discovery and analysis. It does not specify or recommend any solutions, so no fixes here, just the tea ☕

Table of Contents 📑

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  OPES Data Flow Threats . . . . . . . . . . . . . . . . . . . .  4
       2.1.  OPES Flow Network Level Threats  . . . . . . . . . . . .  5
             2.1.1.  Connection-Flow Denial-of-Service (DoS). . . . .  6
             2.1.2.  Threats to Network Robustness. . . . . . . . . .  6
       2.2.  OPES Flow Application Level Threats. . . . . . . . . . .  6
             2.2.1.  Unauthorized OPES Entities . . . . . . . . . . .  6
             2.2.2.  Unauthorized Actions of legitimate OPES Entities  7
             2.2.3.  Unwanted Content Transformations . . . . . . . .  7
             2.2.4.  Corrupted Content  . . . . . . . . . . . . . . .  7
             2.2.5.  Threats to Message Structure Integrity . . . . .  8
             2.2.6.  Granularity of Protection  . . . . . . . . . . .  8
             2.2.7.  Risks of Hop-by-Hop Protection . . . . . . . . .  8
             2.2.8.  Threats to Integrity of Complex Data . . . . . .  8
             2.2.9.  Denial of Service (DoS)  . . . . . . . . . . . .  9
             2.2.10. Tracing and Notification Information . . . . . .  9
             2.2.11. Unauthenticated Communication in OPES Flow . . .  9
   3.  Threats to Out-of-Band Data  . . . . . . . . . . . . . . . . .  9
       3.1.  Threats that Endanger the OPES Data Flow . . . . . . . . 10
       3.2.  Inaccurate Accounting Information  . . . . . . . . . . . 10
       3.3.  OPES Service Request Repudiation . . . . . . . . . . . . 11
       3.4.  Inconsistent Privacy Policy  . . . . . . . . . . . . . . 11
       3.5.  Exposure of Privacy Preferences  . . . . . . . . . . . . 11
       3.6.  Exposure of Security Settings  . . . . . . . . . . . . . 11
       3.7.  Improper Enforcement of Privacy and Security Policy  . . 11
       3.8.  DoS Attacks  . . . . . . . . . . . . . . . . . . . . . . 12
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       5.1.  Normative References . . . . . . . . . . . . . . . . . . 12
       5.2.  Informative References . . . . . . . . . . . . . . . . . 12
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14

1. Introduction ✨

Okay so the Open Pluggable Edge Services (OPES) [1] architecture lets cooperative application services (OPES services) happen between a data provider, a data consumer, and zero or more OPES processors 🫶 The services in question analyze and possibly transform application-level messages that get swapped between the data provider and the data consumer. An OPES processor can split up the work of running a service by talking to and collaborating with one or more remote callout servers. All the nitty-gritty architecture details live in [1] 💜

Security threats with respect to OPES can be looked at from different angles 👀 Some risks hit content consumer applications, and some hit data provider applications. These threats mess with the quality and integrity of the data that the apps either produce or consume 😭 The risks can also be sorted by trust within the system (aka OPES service providers) and protection of the system from threats coming from outsiders, like hackers and attackers. Insiders are the parties that are part of the OPES system, and outsiders are entities that are not participating in it 🍓

It must be noted that not everyone in an OPES delivery path is equally trusted 🙈 Each OPES administrative trust domain must protect itself from all outsiders. It may also have a limited trust relationship with another OPES administrative domain for certain purposes, which is very chill but also very careful 🌈

OPES service providers must use authentication as the basis for building trust relationships between administrative domains 🔐 Insiders can intentionally or unintentionally cause harm and damage to the data consumer and data provider applications. That can happen through bad system configuration, running bad software, or, if their networks get compromised, by inside or outside hackers 💀

Depending on the deployment scenario, trust within the OPES system is based on a set of transitive trust relationships between the data provider application, the OPES entities, and the data consumer application 🦋 Threats to OPES entities can show up at the OPES flow level, the network level, or both ✨

When thinking about threats to the OPES system, the document follows a threat analysis model. It identifies threats from the perspective of how they will affect the data consumer and the data provider applications 💅

Again, the main goal of this document is threat discovery and analysis 🎯 The document does not specify or recommend any solutions.

It is important to mention that the OPES architecture has a lot in common with other so-called overlay networks, especially web caches and content delivery networks (CDN) (see [2], [4]) 🌸 This document focuses on threats that are introduced by the existence of the OPES processor and callout servers. Security threats specific to content services that do not use the OPES architecture are out-of-scope here 🙅‍♀️ However, this document can be used as input when considering security implications for web caches and CDNs, so it's not totally useless for them 🧚

The document is organized like this: Section 2 discusses threats to the OPES data flow on the network and application level, Section 3 discusses threats to other parts of the system, and Section 4 discusses security considerations 🎀

2. OPES Data Flow Threats 🌊

Threats to the OPES data flow can affect the data consumer and data provider applications 😤 At the OPES flow level, threats can happen at Policy Enforcement Points and Policy Decision Points [3], and along the OPES flow path where network elements are used to process the data.

A serious problem is posed by the very fact that the OPES architecture is based on widely adopted protocols (HTTP is used as an example) 😭 The architecture document specifically requires that "the presence of an OPES processor in the data request/response flow SHALL NOT interfere with the operations of non-OPES aware clients and servers". This makes OPES way easier to deploy, which is iconic, but on the other hand, a vast majority of clients (browsers) won't be able to use any safeguards that get added as base protocol extensions 🥲

Think about the usual data consumer, who might be asking questions like: Where does this content come from? Can I get it another way? What's the difference? Is it legit? 🤔 Even if there are facilities and technical expertise around to chase these questions, checking every single result that thoroughly is prohibitively expensive in terms of time and effort. OPES-aware content providers may try to protect themselves by adding verification scripts and special page structures 🛡️ OPES-aware end users may use special tools. In all other cases (non-OPES aware clients and servers), protection relies on monitoring services and investigating anomalies that occasionally get discovered 👀

An OPES system poses a special danger as a possible base for classical man-in-the-middle attacks 🚨 One reason these attacks are relatively rare is that it's hard to find an appropriate base. You need a traffic interception point controlling a large flow of data and an application codebase running on high-performance hardware, with enough performance to analyze and possibly modify all passing data. An OPES processor meets that definition, so this calls for special attention to protection measures at all levels of the system 🫣

Any compromise of an OPES processor or remote callout server can have a ripple effect on the integrity of the affected OPES services across all service providers that use the service. To mitigate this threat, appropriate security procedures and tools (e.g., a firewall) should be applied. 🔥

Specific threats can exist at the network level and at the OPES data flow level 🌈

2.1. OPES Flow Network Level Threats 🛰️

OPES processors and callout servers are susceptible to network level attacks from outsiders, or from the networks of other OPES service providers (for example, if the network of a contracted OPES service is compromised) 😬

The OPES architecture is based on common application protocols that do not provide strong guarantees of privacy, authentication, or integrity 🙃 The IAB considerations [4] require that the IP address of an OPES processor be accessible to data consumer applications at the IP addressing level. That requirement limits how well service providers can position the OPES processor behind firewalls, and it may expose the OPES processor and remote callout servers to network level attacks 💔 For example, using TCP/IP as a network level protocol makes OPES processors subject to many known attacks, such as IP spoofing and session stealing 🕵️‍♀️

The OPES system is also susceptible to a bunch of security threats that are commonly associated with network infrastructure. These include snooping, denial of service, sabotage, vandalism, industrial espionage, and theft of service 😱

There are best practice solutions to mitigate network level threats 💅 It is recommended that the security of the OPES entities at the network level be enhanced using known techniques and methods that minimize the risks of IP spoofing, snooping, denial of service, and session stealing ✨

At the OPES flow level, connection-level security between the OPES processor and callout servers is a big deal 🔑 For example, it is possible to spoof the OPES processor or the remote callout server. There are also threats to data confidentiality between the OPES processor and the remote callout server in an OPES flow 🫠

The next subsections cover possible DoS attacks on an OPES processor, a remote callout server, or a data consumer application, plus network robustness 🌸

2.1.1. Connection-Flow Denial-of-Service (DoS) 💥

okay bestie, so OPES processors, callout servers, and data consumer applications can all be vulnerable to DoS attacks 😭 and DoS attacks come in lots of flavors. One example is when a malicious node floods an OPES processor or callout server with spurious service requests, which leaves the legit data traffic with no resources to actually get served. We're talking CPU cycles, memory, network interfaces, etc. 🫠 A Denial-of-Service attack can be selective, generic, or random about which communication streams it hits, so it's giving chaos 🌪️

Distributed DoS is also a thing 💀 like, an attacker can successfully direct multiple nodes over the network to send spurious service requests to an OPES processor (or callout server) all at once. Iconic villain behavior, honestly 🦹‍♀️

2.1.2. Threats to Network Robustness 🕸️

okay so if an OPES implementation violates end-to-end addressing principles, it could endanger the Internet infrastructure by complicating routing and connection management. And if it doesn't use flow-control principles for managing connections, or if it interferes with end-to-end flow control of connections it didn't originate, then it could cause Internet congestion 🚗💨 not it.

An implementation that violates the IAB requirement of explicit IP level addressing (for example, by adding OPES functional capabilities to an interception proxy) may defeat some of the protective mechanisms and safeguards built into the OPES architecture. The safeguards are literally the whole point, so this is a big no 🙅‍♀️

2.2. OPES Flow Application Level Threats ✨

At the content level, threats to the OPES system can come from outsiders or insiders. The threat from outsiders is frequently intentional. Threats from insiders can be intentional or accidental. Accidents may result from programming or configuration errors that result in bad system behavior 🥴

Application level problems and threats to the OPES systems are discussed below 👇

2.2.1. Unauthorized OPES Entities 🕵️‍♀️

Although one party authorization is mandated by the OPES architecture, such authorization occurs out-of-band. Discovering the presence of an OPES entity and verifying authorization requires special actions and may present a problem 🤔

Adding notification and authorization information to the data messages (by using base protocol extensions) may help, especially if the data consumer's software is aware of such extensions 🫶

2.2.2. Unauthorized Actions of Legitimate OPES Entities 🎭

so according to the OPES architecture, the authorization is not tightly coupled with specific rules and procedures triggered by the rules. Even if a requirement to approve each particular rule and procedure was set, it looks at least impractical, if not impossible, to request such permission from the end user 😩 Authorization granularity extends to transformation classes, but not to individual rules or transformations. The actual rules and triggered procedures may (maliciously or due to a programming error) perform actions that they are not authorized for. Not okay 🙃

2.2.3. Unwanted Content Transformations 🙅‍♀️

an authorized OPES service may perform actions that do not adhere to the expectations of the party that gave the authorization for the service. Examples may include ad flooding by a local ad insertion service or use of inappropriate policy by a content filtering service 📢💀

on the other hand, an OPES entity acting on behalf of one party may perform transformations that another party deems inappropriate. Examples may include replacing ads initially inserted by the content provider or applying filtering transformations that change the meaning of the text. The drama is real 🎬

2.2.4. Corrupted Content 🦠

The OPES system may deliver outdated or otherwise distorted information due to programming problems or as a result of malicious attacks. For example, a compromised server, instead of performing an OPES service, may inject bogus content. Such an action may be an act of cyber-vandalism (including virus injection) or intentional distribution of misleading information (such as manipulations with financial data) 😱

A compromised OPES server or malicious entity in the data flow may introduce changes specifically intended to cause improper actions in the OPES server or callout server. These changes may be in the message body, headers, or both. This type of threat is discussed in more detail below 👀

2.2.5. Threats to Message Structure Integrity 🧩

An OPES server may add, remove, or delete certain headers in a request and/or response message (for example, to implement additional privacy protection or assist in content filtering). Such changes may violate end-to-end integrity requirements or defeat services that use information provided in such headers (for example, some local filtering services or reference-based services). Headers are fragile, bestie 🥹

2.2.6. Granularity of Protection 🔍

OPES services have implicit permission to modify content. However, the permissions generally apply only to portions of the content, for example, URL's between particular HTML tags, text in headlines, or URL's matching particular patterns. In order to express such policies, one must be able to refer to portions of messages and to detect modifications to message parts 🎯

Because there is currently very little support for policies that are expressed in terms of message parts, it will be difficult to attribute any particular modification to a particular OPES processor, or to automatically detect policy violations. Lowkey a mess rn 😭

a fine-grained policy language should be devised, and it could be enforced using digital signatures. This would avoid the problems inherent in hop-by-hop data integrity measures (see next section) ✍️✨

2.2.7. Risks of Hop-by-Hop Protection 🔐

Generally, OPES services cannot be applied to data protected with end-to-end encryption methods because the decryption key cannot be shared with OPES processors without compromising the intended confidentiality of the data. This means that if the endpoint policies permit OPES services, the data must either be transmitted without confidentiality protections or an alternative model to end-to-end encryption must be developed, one in which the confidentiality is guaranteed hop-by-hop. Extending the end-to-end encryption model is out of scope of this work 🙈

OPES services that modify data are incompatible with end-to-end integrity protection methods, and this work will not attempt to define hop-by-hop integrity protection methods. It's a whole vibe-clash 💔

2.2.8. Threats to Integrity of Complex Data 🧵

The OPES system may violate data integrity by applying inconsistent transformations to interrelated data objects or references within the data object. Problems may range from a broken reference structure (modified/missing targets, references to wrong locations or missing documents) to deliberate replacement/deletion/insertion of links that violate intentions of the content provider. Links out here looking chaotic 🔗😵

2.2.9. Denial of Service (DoS) 🚫

The data consumer application may not be able to access data if the OPES system fails for any reason 😭

A malicious or malfunctioning node may be able to block all traffic. The data traffic destined for the OPES processor (or callout server) may not be able to use the services of the OPES device. The DoS may be achieved by preventing the data traffic from reaching the processor or the callout server. Blocked at the door, no cap 🚪

2.2.10. Tracing and Notification Information 📣

Inadequate or vulnerable implementation of the tracing and notification mechanisms may defeat safeguards built into the OPES architecture 😤

Tracing and notification facilities may become a target of malicious attack. Such an attack may create problems in discovering and stopping other attacks. Bestie, who watches the watchers 👁️

The absence of a standard for tracing and notification information may present an additional problem. This information is produced and consumed by the independent entities (OPES servers/user agents/content provider facilities). This calls for a set of standards related to each base protocol in use 📚✨

2.2.11. Unauthenticated Communication in OPES Flow 🔓

There are risks and threats that could arise from unauthenticated communication between the OPES server and callout servers. Lack of use of strong authentication between OPES processors and callout servers may open security holes whereby DoS and other types of attacks (see sections [2 and 3]) can be performed. Security holes = not the vibe 🚨

3. Threats to Out-of-Band Data 🗝️

The OPES architecture separates a data flow from a control information flow (loading rulesets, trust establishment, tracing, policy propagation, etc.). There are certain requirements set for the latter, but no specific mechanism is prescribed. This gives more flexibility for implementations, but creates more burden for implementers and potential customers to ensure that each specific implementation meets all requirements for data security, entity authentication, and action authorization 💅

In addition to performing correct actions on the OPES data flow, any OPES implementation has to provide an adequate mechanism to satisfy requirements for out-of-band data and signaling information integrity 🧠

Whatever the specific mechanism may be, it inevitably becomes subject to multiple security threats and possible attacks. The way the threats and attacks may be realized depends on implementation specifics, but the resulting harm generally falls into two categories: threats to OPES data flow and threats to data integrity. The specific threats are: 👇

3.1. Threats that Endanger the OPES Data Flow 🚨

Any weakness in the implementation of a security, authentication, or authorization mechanism may open the door to the attacks described in section 2 🚪😬

An OPES system implementation should address all these threats and prove its robustness and ability to withstand malicious attacks or networking and programming problems. No skipping the homework, periodt 📝💪

3.2. Inaccurate Accounting Information 💸

Collecting and reporting accurate accounting data may be vital when OPES servers are used to extend a business model of a content provider, service provider, or as a basis for third party service. The ability to collect and process accounting data is an important part of OPES' system functionality. This functionality may be challenged by distortion or destruction of base accounting data (usually logs), processed accounting data, accounting parameters, and reporting configuration 📉

As a result, a data consumer may be inappropriately charged for viewing content that was not successfully delivered, or a content provider or independent OPES services provider may not be compensated for the services performed. Ugh, the money stuff is so unfair 😤💰

The OPES system may use accounting information to distribute resources between different consumers or limit resource usage by a specific consumer. In this case, an attack on the accounting system (by distortion of data or issuing false configuration commands) may result in incorrect resource management and DoS by artificial resource starvation 🥀

3.3. OPES Service Request Repudiation 🙅

An entity (producer or consumer) might make an authorized request and later claim that it did not make that request. As a result, an OPES entity may be held liable for unauthorized changes to the data flow, or will be unable to receive compensation for a service. The "it wasn't me" energy is so real 🫠

There should be a clear request that this service is required, and there should be a clear course of action on behalf of all parties. This action should have a request, an action, a non-repudiable means of verifying the request, and a means of specifying the effect of the action. Receipts, receipts, receipts 🧾🦋

3.4. Inconsistent Privacy Policy 🎀

okay so the OPES entities might have privacy policies that don't match the data consumer application or the content provider application 😬 which is so messy, bestie.

privacy stuff gets even more chaotic when OPES entities, content providers, and end users are in different jurisdictions with different rules and different levels of legal protection 🌍. the end user might not even realize they don't have the protection they're expecting 💀. and the content provider could face legal risk for not following regulations they didn't even know existed 😭.

3.5. Exposure of Privacy Preferences 🙈

the OPES system might accidentally, or maliciously (yikes), expose end user privacy settings and requirements. not it 🫣.

3.6. Exposure of Security Settings 🔐

there are risks that the OPES system exposes end user security settings while it's handling requests and responses. user data must be handled as sensitive system information and protected against accidental and deliberate disclosure. this is non-negotiable, periodt 💅.

3.7. Improper Enforcement of Privacy and Security Policy 🚨

OPES entities are part of the content distribution system, so they take on certain obligations to support the security and privacy policies set by the content producer and/or end user. ngl, the scary part is that these policies might not get properly implemented and enforced 😰. the data consumer application may not even know its protections are no longer in effect 💀.

there's also the chance of security and privacy leaks from accidental misconfiguration, or from misunderstanding which rules are in effect for a particular user or request 🙃.

and privacy and security parts of these systems can be targeted by malicious attacks, so being able to withstand those attacks is of paramount importance 👑🔥.

3.8. DoS Attacks 💥

DoS attacks come in various types 🌪️. one type works by overloading the client. for example, an intruder can direct an OPES processor to send numerous responses to a client 📨. there's also extra DoS risk from a rule misconfiguration that would make the OPES processor ignore a data consumer application 😱.

4. Security Considerations 🛡️

this document discusses multiple security and privacy issues related to the OPES services. the whole thing is serious business, so pay attention 🫶.

5. References 📚

5.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] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and R. Penno, "OPES Use Cases and Deployment Scenarios", RFC 3752, April 2004.
  • [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.

5.2. Informative References

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

6. Acknowledgements 🌸

many thanks to T. Chan (Nokia) and A. Beck (Lucent) 🫶.

7. Authors' Addresses 💌

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

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


Oskar Batuner
Independent consultant

EMail: batuner@attbi.com


Bindignavile Srinivas
Nokia
5 Wayside Road
Burlington, MA  01803
USA

EMail: bindignavile.srinivas@nokia.com


Markus Hofmann
Bell Labs/Lucent Technologies
Room 4F-513
101 Crawfords Corner Road
Holmdel, NJ  07733
US

Phone: +1 732 332 5983
EMail: hofmann@bell-labs.com


Hilarie Orman
Purple Streak Development

EMail: ho@alum.mit.edu

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/SHE 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 procedures with respect to rights in RFC 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