Leveraging Structural Symmetry for IoT Security: A Recursive InterNetwork Architecture Perspective ^†

Abstract

The Internet of Things (IoT) has transformed modern life through interconnected devices enabling automation across diverse environments. However, its reliance on legacy network architectures has introduced significant security vulnerabilities and efficiency challenges—for example, when Datagram Transport Layer Security (DTLS) encrypts transport-layer communications to protect IoT traffic, it simultaneously blinds intermediate proxies that need to inspect message contents for protocol translation and caching, forcing a fundamental trade-off between security and functionality. This paper presents an architectural solution based on the Recursive InterNetwork Architecture (RINA) to address these issues. We analyze current IoT network stacks, highlighting their inherent limitations—particularly how adding security at one layer often disrupts functionality at others, forcing a detrimental trade-off between security and performance. A central principle underlying our approach is the role of structural symmetry in RINA’s design. Unlike the heterogeneous, protocol-specific layers of TCP/IP, RINA exhibits recursive self-similarity: every Distributed IPC Facility (DIF), regardless of its position in the network hierarchy, instantiates identical mechanisms and offers the same interface to layers above. This architectural symmetry ensures predictable, auditable behavior while enabling policy-driven asymmetry for context-specific security enforcement. By embedding security within each layer and allowing flexible layer arrangement, RINA mitigates common IoT attacks and resolves persistent issues such as the inability of Performance Enhancing Proxies to operate on encrypted connections. We demonstrate RINA’s applicability through use cases spanning smart homes, healthcare monitoring, autonomous vehicles, and industrial edge computing, showcasing its adaptability to both RINA-native and legacy device integration. Our mixed-methods evaluation combines qualitative architectural analysis with quantitative experimental validation, providing both theoretical foundations and empirical evidence for RINA’s effectiveness. We also address emerging trends including AI-driven security and massive IoT scalability. This work establishes a conceptual foundation for leveraging recursive symmetry principles to achieve secure, efficient, and scalable IoT ecosystems.

1. Introduction

Symmetry is a foundational principle in secure system design [1]. From cryptographic algorithms that rely on mathematical symmetries to access control models built on symmetric trust relationships, the presence of structural regularity enables formal verification, predictable behavior, and comprehensive security coverage. Conversely, architectural asymmetry—where different components of a system implement fundamentally different mechanisms with incompatible semantics—creates security gaps that are notoriously difficult to close. This paper argues that the persistent security failures plaguing the Internet of Things (IoT) are not merely implementation flaws or protocol weaknesses, but rather symptoms of a fundamental asymmetry embedded in the network architectures upon which IoT systems are built.

The TCP/IP protocol stack, which underpins virtually all IoT communications today, exemplifies architectural asymmetry. Each layer—physical, data link, network, transport, and application—implements distinct mechanisms with different abstractions, naming schemes, security models, and failure semantics. The network layer uses IP addresses; the transport layer uses ports; the application layer uses URIs. Security at the network layer (IPsec) operates independently from security at the transport layer (TLS/DTLS), which in turn differs fundamentally from application-layer security mechanisms. This heterogeneity means that securing one layer provides no guarantees about adjacent layers, and worse, security measures at one layer frequently conflict with functionality at others.

Consider the consequences of this asymmetry in IoT environments. When Datagram Transport Layer Security (DTLS) [2] encrypts transport-layer communications to protect Constrained Application Protocol (CoAP) traffic [3], it simultaneously blinds CoAP proxies that need to inspect message contents for protocol translation and caching—core functions in resource-constrained IoT deployments. When IPsec encrypts at the network layer, it conceals the transport-layer information that Performance Enhancing Proxies (PEPs) require to optimize throughput over wireless links [4]. These are not edge cases but structural inevitabilities: in an architecturally asymmetric stack, securing any single layer necessarily obscures information that other layers depend upon. The result is a persistent, unresolvable tension between security and functionality [5].

This architectural asymmetry manifests across multiple dimensions in IoT systems:

• Mechanism asymmetry: Each protocol layer implements security through different mechanisms—encryption algorithms, authentication handshakes, access control lists—that do not compose cleanly. A vulnerability patched at one layer may remain exploitable through another.
• Scope asymmetry: Security boundaries do not align with communication boundaries. Transport-layer security protects end-to-end connections, but IoT data often traverses proxies, gateways, and edge processors that legitimately need access to payload contents.
• Policy asymmetry: Different layers enforce different policies through incompatible mechanisms. Network-layer firewalls cannot enforce application-layer access controls; transport-layer encryption cannot implement network-layer traffic shaping.
• Semantic asymmetry: The meaning of “secure communication” differs across layers. Network-layer security protects packets; transport-layer security protects streams; application-layer security protects objects. These semantic mismatches create coverage gaps.

Figure 1 illustrates these asymmetry dimensions concretely. The left panel shows how TCP/IP layers employ fundamentally different abstractions: IP addresses at the network layer, port numbers at the transport layer, and URIs at the application layer—each with incompatible security mechanisms. The right panel demonstrates how these asymmetries manifest as operational conflicts in IoT deployments: transport-layer encryption blinds application-layer proxies, while network-layer security conceals the information that performance optimizers require.

The scale of the IoT ecosystem amplifies these asymmetry-induced vulnerabilities. Recent analyses project 39–40 billion connected IoT devices by 2030 [6], operating across smart homes, healthcare systems, industrial facilities, and urban infrastructure. Market forecasts estimate the IoT sector will reach USD 2.6–2.7 trillion by 2030 [7]. Yet comprehensive security studies consistently identify the network stack as the primary source of IoT vulnerabilities [8,9,10]. The problem is not insufficient security mechanisms—the field has produced countless protocols, frameworks, and standards—but rather that these mechanisms cannot be coherently integrated within an architecturally asymmetric foundation.

This paper proposes a fundamentally different approach: rather than adding security mechanisms atop an asymmetric architecture, we advocate rebuilding IoT communications on a foundation of structural symmetry. The Recursive InterNetwork Architecture (RINA) [11] provides exactly this foundation. RINA’s central insight is that computer networking reduces to a single problem—Inter-Process Communication (IPC)—applied recursively at different scopes. Every layer in RINA, called a Distributed IPC Facility (DIF), instantiates identical mechanisms and presents the same interface to the layers above, regardless of whether it operates at link scope, network scope, or global scope.

This recursive self-similarity constitutes a form of architectural symmetry with profound security implications:

• Symmetric mechanisms ensure uniform security coverage. Because every DIF implements the same security functions—authentication, access control, encryption, integrity verification—there are no “security-free” layers. Unlike TCP/IP, where protocols like 6LoWPAN lack native security mechanisms [5], RINA guarantees that security capabilities exist at every layer by construction.
• Symmetric structure enables formal verification. Security properties verified for one DIF hold structurally for all DIFs. This dramatically reduces the verification burden compared to heterogeneous stacks where each layer requires independent security analysis.
• Symmetric interfaces eliminate cross-layer conflicts. Because all DIFs present the same API, security mechanisms at one layer cannot inadvertently break functionality at another. The PEP problem dissolves: intermediate DIFs can legitimately access and process traffic within their scope without violating end-to-end security guarantees of higher-layer DIFs.

Crucially, RINA’s structural symmetry does not imply behavioral uniformity. The architecture cleanly separates mechanisms (invariant across all DIFs) from policies (configurable per DIF). This separation enables what we term controlled symmetry-breaking: the ability to customize security policies, Quality of Service parameters, and addressing schemes at each layer without altering the underlying symmetric structure. A sensor-level DIF may employ lightweight encryption appropriate for constrained devices, while a backbone DIF implements stronger cryptographic policies—yet both use the same mechanism framework. This interplay between structural symmetry and policy-driven asymmetry is central to RINA’s security model: symmetric mechanisms ensure predictable, auditable behavior, while asymmetric policies enable context-specific security enforcement.

This paper provides a comprehensive analysis of how RINA’s symmetry properties address IoT security challenges that have proven intractable in asymmetric architectures. Our contributions, framed explicitly through the lens of architectural symmetry, include:

• Diagnosis of asymmetry-induced vulnerabilities: We systematically analyze current IoT network stacks, demonstrating how their architectural asymmetry creates security gaps, redundant functionality, and irreconcilable conflicts between security and performance. Our aim is to show that IoT security failures are mainly structural rather than incidental.
• Symmetry-based architectural solution: We present RINA as a foundation for IoT security, explicating how its recursive self-similarity, mechanism invariance, and controlled policy variance address each category of asymmetry-induced vulnerability. We formalize the relationship between RINA’s symmetry properties and specific security guarantees.
• Attack-to-symmetry mapping: We provide a systematic classification of IoT attacks across network, middleware, and application layers, mapping each attack type to the RINA symmetry properties that enable its mitigation. This mapping is analyzed to assess whether RINA’s security advantages derive from architectural principles rather than ad hoc countermeasures.
• Empirical validation of recursive security: We reinterpret quantitative experimental results from our previous work [12] through the symmetry framework developed in this paper. This analysis tests the recursive security hypothesis—that security mechanisms operating within RINA’s symmetric DIF boundaries outperform equivalent mechanisms that ignore the recursive structure—and examines the conditions under which scope-aligned detection provides measurable advantages.
• Cross-domain applicability: We demonstrate RINA’s practical applicability through use cases spanning smart homes, healthcare monitoring, autonomous vehicles, and industrial edge computing. These cases illustrate how structural symmetry enables consistent security guarantees across heterogeneous IoT domains—a property unattainable in asymmetric architectures.

This paper substantially extends our earlier work on RINA for IoT security [13] and also provides a symmetry-based analysis of Learning-in-the-Middle anomaly detection [12]. The present manuscript makes three primary advances: (i) it reframes RINA’s security advantages explicitly through a symmetry/invariance lens appropriate for this venue, (ii) it provides an extended and systematically structured attack–feature–mitigation mapping organized around symmetry properties, (iii) it presents significantly expanded use case studies that demonstrate the practical implications of architectural symmetry for IoT security, and (iv) it reinterprets previously published experimental results through the symmetry lens, demonstrating that the Symmetry Scoping principle has predictive power for real security outcomes.

Given the architectural nature of our claims, we adopt a mixed-methods research approach. The qualitative component provides theoretical analysis of how RINA’s symmetry properties address specific vulnerability classes—essential for establishing the why behind security improvements. The quantitative component provides empirical validation through controlled experiments—essential for establishing that security improvements materialize in practice. This combination allows us to move beyond architectural advocacy toward evidence-based assessment of symmetry’s security benefits.

The remainder of this paper is organized as follows: Section 2 discusses the current security challenges confronting IoT, particularly within its network stack, followed by a summary of these challenges in Section 3. Section 4 justifies the choice of method in our research. Section 5 introduces the Recursive InterNetwork Architecture (RINA). Section 6 details the comprehensive security features of RINA. Section 7 illustrates how RINA can effectively address the identified IoT security challenges. Section 8 presents diverse use cases where RINA can be effectively employed in IoT environments. Section 9 shows results of our experiments. Section 10 discusses future directions of our study. Finally, Section 11 summarizes our findings and concludes the paper.

2. Challenges in Current IoT Network Stacks

The Internet of Things (IoT) demands a robust and secure communication platform capable of efficiently bridging diverse domains. However, many of the security and efficiency challenges faced by IoT systems are deeply rooted in the fundamental architectural designs of their network stacks. Current efforts to enhance IoT security and performance primarily follow two distinct approaches.

TCP/IP-Based Solutions: These approaches build upon the existing Internet architecture by adapting and extending TCP/IP protocols to meet IoT-specific requirements. While leveraging well-established standards and infrastructure, this strategy often struggles to fully address the unique constraints and security demands of IoT ecosystems, such as resource limitations, heterogeneity, and scalability.

Novel Architectural Paradigms: This category includes innovative frameworks such as Information-Centric Networking (ICN), which reimagine network architecture from the ground up to better align with IoT needs. While these approaches offer promising solutions by addressing the limitations of TCP/IP-based models, they face challenges in terms of widespread adoption, interoperability with existing systems, and maturity of deployment.

Both strategies aim to tackle critical issues such as scalability, heterogeneity, and security in IoT networks, but each comes with its own set of limitations and trade-offs. In the following subsections, we delve into the specific challenges posed by current IoT network stacks, examining how their architectural foundations impact security, efficiency, and overall performance in IoT deployments.

2.1. TCP/IP-Based Stack

The predominant approach in IoT networking has been to align IP-based communication protocols with IoT devices, forming a communication stack that extends the traditional Internet architecture to the IoT domain. This is rooted in the vision of IoT where everyday objects equipped with sensing and actuating capabilities cooperate with computer systems over the Internet.

Figure 2 illustrates a typical IP-based IoT network stack with commonly used protocols at each layer. At the physical and MAC layers, IEEE 802.15.4 [14] is widely adopted for low-power wireless communication. The 6LoWPAN protocol [15] enables the transmission of IPv6 packets over IEEE 802.15.4 networks, facilitating Internet connectivity. On top of 6LoWPAN, the Routing Protocol for Low-Power and Lossy(RPL) Networks [16] provides routing functionality tailored for constrained environments. For transport layer security, TLS 1.3 [17] and its datagram counterpart DTLS 1.3 [18] are used over TCP and UDP, respectively. At the application layer, the Constrained Application Protocol (CoAP) [19] operates over UDP (and DTLS), offering web transfer capabilities with some limited congestion control features.

While this stack closely resembles the traditional TCP/IP stack, with adaptations to accommodate the constraints of IoT devices, the large-scale deployment of IP-based IoT solutions remains challenging [20]. The inherent limitations of the TCP/IP architecture—such as its end-to-end communication model, lack of inherent security mechanisms, and difficulties in supporting mobility and multicast—make it less than ideal for the dynamic and resource-constrained IoT environments. Additionally, layering multiple protocols can introduces inefficiencies and complexities that are particularly problematic for devices with limited processing power and energy resources.

2.2. Information-Centric Networking (ICN)-Based Stack

In contrast to IP-based approaches, Information-Centric Networking (ICN) represents a paradigm shift by focusing on named data rather than host addresses. In ICN, content is identified by unique names, independent of its location or the application, facilitating features such as in-network caching, replication, and content-based security [20].

Although ICN was not originally designed with IoT in mind, its principles have been adapted to address some of the unique requirements of IoT systems. By decoupling content from location, ICN can inherently support mobility, intermittent connectivity, and efficient content distribution, which are common in IoT scenarios.

However, the multifaceted and complex nature of IoT presents significant challenges to the design and implementation of ICN-based solutions [20]. Issues such as naming and addressing in vast IoT networks, security of content dissemination, and efficient handling of constrained devices require careful consideration. Moreover, despite ongoing standardization efforts within the ICN Research Group (ICNRG) [21], there is considerable debate within the ICN community regarding potential security and performance issues that ICN might encounter in the IoT context [22].

Additionally, ICN’s departure from the established IP-based infrastructure raises concerns about interoperability with existing systems, the overhead of deploying a new architecture, and the maturity of ICN protocols and implementations. These factors contribute to the challenges in achieving widespread adoption of ICN-based solutions in IoT deployments.

3. Summary of IoT Networking Challenges

Despite extensive research on securing IoT systems, significant open issues remain concerning the layers, protocols, and their associated vulnerabilities [5,9]. We contend that many IoT security challenges primarily originate from the architectural design of IoT network stacks. The main challenges are described below.

3.1. IoT Network Stack Challenges (Ch1)

IoT security challenges in IP-based frameworks largely stem from the architectural design of the network stack [13]. Comprehensive studies on IoT security [9] confirm that many issues originate from the currently employed network stack protocols of IoT devices and their interoperability with the Internet. One significant flaw with IP is the improper use of the concept of layer scope [23], which has been diluted over time due to incremental updates. While some research efforts (e.g., [24]) focus on presenting secure IoT architectures, they typically operate at higher layers without addressing the underlying network stack. In contrast, this paper fundamentally examines the lower layers, specifically the network stack and its protocols.

Despite lessons learned from the Internet, the IoT network stack continues to exhibit similar security issues. For instance, as illustrated in Figure 2, the 6LoWPAN protocol does not define any security mechanisms itself, although it allows the use of IPsec to provide security between two endpoints. However, no specific method has been widely adopted for 6LoWPAN [5]. Moreover, the 6LoWPAN Border Router typically does not perform authentication, leaving IoT networks vulnerable [9].

Furthermore, encryption at the routing layer obscures necessary information from the upper layers. This issue is exemplified by the challenges faced by Performance Enhancing Proxies (PEPs) [25] in wireless networks. PEPs cannot break the end-to-end congestion control loop to initiate a new one tailored to the environment’s properties (e.g., wired or wireless) [26] because encryption prevents them from accessing transport layer information. Although proposals for smart gateways (e.g., [27,28]) aim to connect things to the Internet, the same problem persists [5,29].

At the routing layer, RPL [30] is commonly used, but it lacks definitions for protecting communications and operations from internal attackers and misses key security features [5]. At the transport and application layers, DTLS is commonly employed to ensure end-to-end security over CoAP. However, as noted in [3,5], DTLS does not support multicast communication, which is highly required in IoT networks. Additionally, the end-to-end security provided by DTLS complicates the operation of CoAP proxies along the communication path. This complication has led to efforts to secure CoAP communications and object security at the application layer rather than relying solely on transport-layer security provided by DTLS; however, this approach is still immature. Despite prior efforts to address these issues in the Internet context, IoT continues to face similar challenges.

Moreover, ICN-based stacks face significant challenges in the IoT context. ICN-IoT not only connects a vastly greater number of devices compared to most other networks, but it also assigns unique names to the content generated by these devices. This combination of massive connectivity and content-specific naming imposes considerable difficulties in managing security protocols and optimizing performance within IoT environments.

3.2. Redundant Functionality Across Layers (Ch2)

Another significant challenge is the redundant implementation of similar security functionalities across different layers in IoT network stacks, leading to inefficiency and increased complexity. A prime example is encryption, which is often implemented at multiple levels:

• Application layer: Protocols like HTTPS or MQTT over TLS;
• Network layer: IPsec for encrypting IP packets;
• Link layer: WPA3 for Wi-Fi or Bluetooth Low Energy (BLE) secure connections.

This duplication results in several significant issues. Firstly, it increases overhead and power consumption, as each layer of encryption adds computational cost—particularly problematic for resource-constrained IoT devices. Secondly, it creates complex key management challenges; managing encryption keys at multiple layers becomes intricate, increasing the risk of misconfigurations or vulnerabilities. Thirdly, potential conflicts can arise where encryption at one layer interferes with optimizations or security measures at another. For instance, network-layer encryption may prevent transport-layer optimizations that rely on packet inspection. Finally, maintenance becomes more challenging, as vulnerabilities discovered may need to be patched at multiple layers, complicating the update process.

This redundancy not only represents an inefficient use of resources but also introduces unnecessary complexity, contradicting the principle of avoiding duplication across layers. Each reimplementation risks introducing new vulnerabilities into the system—particularly critical in the context of security functions where minor oversights can lead to significant breaches.

Furthermore, the multiplication of similar functions in different layers complicates the process of patching and updating security protocols, increasing the system’s vulnerability to threats over time. It also hinders the development of modular, reusable components that could enhance the scalability and adaptability of the system.

3.3. Challenges with Global Addressability and Large Address Spaces (Ch3)

The rapid proliferation of IoT devices has necessitated the adoption of IPv6 to accommodate the vast address space required [31]. While IPv6 facilitates universal connectivity by providing each IoT device with a unique, globally routable IP address, this transition introduces a complex set of challenges related to addressing, scalability, and network segmentation.

Allocating globally addressable IPs to every IoT device significantly increases the attack surface. The high visibility of these devices on the global Internet makes them more susceptible to identification and targeting by malicious actors. This vulnerability is further exacerbated by the immense scale of IoT networks, which can encompass millions or even billions of devices, rendering traditional security approaches increasingly untenable [32].

Managing such an extensive address space presents substantial practical difficulties. As IoT deployments expand, efficiently administering and maintaining this vast addressing scheme becomes increasingly complex and resource-intensive. Implementing robust security measures across a rapidly growing network of diverse devices intensifies these scalability challenges.

Moreover, exposing every IoT device to the global Internet is often unnecessary and undesirable. Many devices can operate effectively within local or private networks, underscoring the need for more nuanced, scope-dependent addressing strategies. This perspective aligns with the principle of network segmentation, where devices are grouped into logical segments based on factors such as functionality, security requirements, or physical location [33].

However, implementing effective network segmentation in IoT environments is challenging. The diverse nature of IoT devices and their varying security needs complicate the establishment of clear segmentation boundaries. Additionally, the dynamic nature of IoT deployments—with devices frequently joining or leaving the network—further complicates segmentation efforts.

Therefore, a more sophisticated approach to addressing and network architecture is needed, one that accommodates the massive scale of IoT deployments while providing flexibility for effective network segmentation. Such an approach should balance the benefits of global addressability with the security advantages of logical isolation all while maintaining the scalability necessary for future growth.

3.4. Balancing Security, Performance, and Resource Constraints (Ch4)

The IoT landscape presents a complex challenge in balancing security, performance, and resource constraints. This trilemma is particularly evident in interconnected IoT applications such as home monitoring and e-health systems, as illustrated in Figure 3.

These applications are designed for patient or elderly health monitoring in residential settings, often with capabilities for emergency interventions [34]. They highlight the varying trust levels and privacy requirements across different interactions. For instance, in emergency situations, caregivers may need immediate access to the home, demonstrating the dynamic and context-dependent nature of security needs in IoT environments. Modern deployments increasingly incorporate edge gateways for local processing, adding another trust boundary that must be secured.

This challenge is further compounded by the inherent resource limitations of many IoT devices [35], which impact the ability to implement robust security measures without compromising device performance or longevity. IoT devices are typically constrained in processing power, memory, and energy capacity, making it difficult to support computationally intensive security protocols.

Additionally, IoT devices frequently rely on Constrained Application Protocol (CoAP) proxies to interface with IoT cloud services and other systems via HTTP-like protocols. These proxies may need to break end-to-end connections or translate protocols to optimize resource utilization, introducing additional security considerations [36]. The need to maintain efficient communication while ensuring stringent security within limited device resources poses a significant challenge.

Moreover, the necessity for multicast communication in IoT networks adds another layer of complexity. While proposals have been made to address multicast in IoT [37], the current inability to secure multicast traffic using Datagram Transport Layer Security (DTLS) [3] presents additional hurdles. This limitation underscores the difficulty of securing IoT communications while maintaining performance efficiency and adhering to resource constraints.

Implementing security measures such as encryption, authentication, and secure key management often requires significant computational resources. In resource-constrained IoT devices, these security operations can lead to increased energy consumption, reduced battery life, and potential performance degradation. This creates a delicate balance between implementing necessary security features and maintaining acceptable device performance and longevity.

In summary, the interplay between security requirements, performance demands, and resource limitations necessitates innovative architectural solutions that can address these challenges holistically in IoT environments.

3.5. Repetition and Evolution of Attacks (Ch5)

A persistent challenge in the IoT landscape is the recurrence and evolution of historical cyberattacks into more sophisticated forms. Despite advancements in IoT protocols and security measures, significant vulnerabilities continue to exist, necessitating ongoing enhancements to safeguard IoT systems [9]. While Distributed Denial of Service (DDoS) attacks exemplify this pattern—where traditional attacks are amplified and adapted to exploit IoT devices—they represent only one facet of a multifaceted problem. The issue extends across a broad spectrum of security threats, each evolving and finding new expressions within the IoT environment.

This adaptation and evolution of attacks are driven by factors unique to IoT, including device heterogeneity, resource constraints, prolonged operational lifespans, and the critical nature of many IoT applications. The diversity of hardware and software platforms among IoT devices makes it challenging to implement standardized security measures. Resource limitations hinder the deployment of robust security protocols, while the long operational lifespans of devices often lead to outdated security mechanisms remaining in use. Furthermore, the critical functions that many IoT devices perform—in sectors like healthcare, infrastructure, and transportation—amplify the potential impact of security breaches.

These factors necessitate not only reactive measures to address existing vulnerabilities but also proactive strategies to anticipate and mitigate future attack vectors. Innovative security architectures are required to adapt to the evolving threat landscape, providing comprehensive protection that accommodates the unique characteristics of IoT devices and networks.

3.6. Future Extensions and Emerging Technologies (Ch6)

The future of IoT is poised for exponential growth, not only in the number of devices but also in capabilities, functionalities, and application domains. While this evolution holds immense promise, it also introduces a new level of security challenges that demand innovative solutions. Although progress has been made in securing individual protocols and layers within the IoT architecture, achieving comprehensive scurity coverage remains elusive, particularly when considering interlayer compatibility and future extensions [38,39].

Emerging extensions in mobility, multicast, and Quality of Service (QoS) further complicate this landscape. Ensuring secure and seamless handovers in highly mobile IoT environments, developing efficient and secure multicast protocols for large-scale networks, and maintaining stringent QoS requirements without compromising security in time-critical applications are paramount challenges.

Moreover, the convergence of IoT with other emerging technologies such as 5G/6G, software-defined networking (SDN), and network function virtualization (NFV) will create complex, heterogeneous environments. Ensuring end-to-end security in these diverse ecosystems while maintaining interoperability and performance will be a significant challenge.

The advent of 6G networks and beyond is set to revolutionize the IoT landscape. These next-generation networks promise ultra-low latency, massive machine-type communications (mMTC), and ultra-reliable low-latency communications (URLLCs). However, they also introduce novel security paradigms:

• AI-Driven Security: The integration of artificial intelligence and machine learning into IoT networks enables predictive security measures but also opens up new attack vectors, such as adversarial machine learning attacks [40].
• Blockchain for IoT: Distributed ledger technologies offer promising solutions for device authentication and data integrity but introduce scalability and energy consumption challenges in resource-constrained IoT environments [41].
• Edge Computing Security: The shift toward edge computing in IoT networks reduces latency but decentralizes security controls, necessitating new approaches to ensure data protection at the network edge [42].

Furthermore, emerging IoT applications will push the boundaries of current security models [43]:

• Tactile Internet: Ultra-low-latency applications like remote surgery and autonomous vehicles require security measures that can operate at unprecedented speeds without compromising effectiveness.
• Massive IoT: The sheer scale of device numbers in future deployments will necessitate scalable security solutions capable of efficiently managing billions of endpoints.
• Cognitive IoT: As IoT devices become more intelligent and autonomous, ensuring the integrity of their decision-making processes becomes crucial, introducing the concept of “cognitive security.”

Addressing these challenges requires a reimagining of IoT security architectures to accommodate rapid advancements and emerging technologies. Innovative solutions must provide comprehensive security coverage across layers and devices while ensuring compatibility with future extensions. The development of adaptable, scalable, and robust security mechanisms is imperative to safeguard the next generation of IoT ecosystems.

3.7. Cross-Domain Synergy and Interoperability (Ch7)

The widespread proliferation of IoT applications across diverse domains presents significant challenges in achieving cross-domain synergy and interoperability. Each domain—such as healthcare, industrial automation, smart homes, or automotive—has developed its unique set of requirements, protocols, and security policies [44]. While this heterogeneity fosters innovation tailored to specific needs, it also introduces substantial obstacles to forming a cohesive and secure IoT ecosystem.

• Protocol Diversity: Each domain has evolved specialized protocols optimized for its specific use cases. For instance, healthcare IoT devices often utilize HL7 FHIR for data exchange, whereas industrial IoT systems might rely on OPC UA or MQTT. Bridging these protocol gaps without compromising functionality or security remains a significant challenge [45].
• Security Paradigms: Security requirements vary dramatically across domains. Healthcare IoT demands strict compliance with privacy regulations like HIPAA, industrial IoT prioritizes integrity and availability, smart home devices must balance user convenience with security, and automotive IoT requires real-time guarantees for safety-critical functions [46].
• Data Interoperability: Beyond protocol compatibility, ensuring semantic interoperability of data across domains is crucial. Developing a common data model that can represent diverse IoT data while preserving context and meaning poses a significant challenge [47].
• Regulatory Compliance: Different domains are governed by distinct regulatory frameworks. Harmonizing these regulations—especially in cross-border scenarios—adds another layer of complexity [48].

Cross-domain communication exacerbates these challenges. The necessity for common protocols and policies for inter-domain interaction introduces potential vulnerabilities. An adversary could exploit the weakest link in this cross-domain chain to compromise the entire network. Therefore, a holistic security approach is required—one that considers the entire ecosystem rather than isolated domains.

Recent developments have seen the emergence of middleware solutions and semantic web technologies aimed at addressing some of these issues. For example, the Web of Things (WoT) architecture proposed by the W3C provides a standard method to describe IoT devices and their interactions, potentially bridging some cross-domain gaps [49]. Additionally, the concept of Digital Twins is gaining traction as a means to create virtual representations of physical IoT devices, facilitating cross-domain interoperability and security management [50].

Addressing these challenges necessitates a multifaceted approach, including:

• Developing flexible, domain-agnostic communication frameworks that can adapt to various protocol requirements.
• Creating comprehensive security models that accommodate diverse security needs while maintaining a cohesive security posture.
• Establishing standardized data models and ontologies to ensure semantic interoperability across domains.

The persistent nature of these challenges—despite numerous attempts to address them at higher layers—underscores the need for a fundamental rethinking of the network stack itself. This realization motivates our exploration of RINA as a potential solution.

4. Methodology

This study employs a mixed-methods research approach, combining qualitative architectural analysis with quantitative experimental validation, to evaluate the potential of the Recursive InterNetwork Architecture (RINA) for IoT security. This hybrid approach allows for a comprehensive understanding of both the theoretical advantages and practical efficacy of RINA.

4.1. Qualitative Analysis

The first phase of our research utilizes a qualitative methodology to explore the fundamental architectural benefits of RINA. This choice is deliberate and appropriate for several reasons. Firstly, the application of RINA to IoT is a novel area, and qualitative methods are effective for investigating emerging concepts [51,52]. This allows us to delve deeply into RINA’s principles without being constrained by predetermined variables. Secondly, the intersection of RINA and IoT involves complex, interrelated factors best analyzed holistically [53]. This aligns with foundational studies such as [9,38].

4.2. Quantitative Experimental Validation

To complement the theoretical analysis, we employ a quantitative approach to empirically validate specific security capabilities of RINA. We develop a simulation environment to model a RINA-based IoT network. We focus on the Layered Threat Detection (LIM) mechanism, evaluating its performance against common IoT attacks. Our evaluation metrics include F1 scores, False Positive Rates (FPRs), and detailed statistical analyses to rigorously assess the effectiveness of the proposed solution compared to global detection strategies.

4.3. Research Steps

Our methodology follows these key steps:

• Analysis of Security Challenges: Identification and categorization of IoT vulnerabilities.
• Architectural Analysis: In-depth examination of RINA’s design principles versus traditional stacks.
• Qualitative Feature Assessment: Mapping RINA capabilities to specific IoT threats.
• Use Case Development: Illustrating practical applications in diverse scenarios (e.g., smart homes, healthcare).
• Experimental Validation: Reinterpretation of the quantitative simulation and statistical results of RINA-based security mechanisms (results of a previous study [12]) through a systematic analysis.

5. Recursive InterNetwork Architecture (RINA)

In light of all the challenges discussed in the previous section, we introduce the Recursive InterNetwork Architecture (RINA) as a potential solution. RINA’s unique approach to network architecture offers promising avenues for addressing the challenges, as we explore in the following sections.

5.1. Introduction

The Recursive InterNetwork Architecture (RINA), presented by John Day in “Patterns in Network Architecture: A return to Fundamentals” [11], is a novel approach in networking architecture trying to avoid architectural problems of TCP/IP and other technologies. Through evaluating it in different use cases (e.g., see [4,23,54,55,56,57]), it is shown that RINA can provide significant benefits to networking by removing architectural obstacles (see [58] for a list of publications on RINA; a comprehensive yet easy-to-read text on RINA can be found in [59]).

As shown in Figure 4, RINA is based on a single type of layer (represented by dashed boxes in the figure), which is repeated as many times as required by the network designer. The layer is called a Distributed IPC Facility (DIF), which is a distributed application that provides IPC services over a given scope to the distributed applications above (which can be other DIFs or regular applications). These IPC services are defined by the DIF API. All DIFs offer the same services through their API and have the same components and structure. However, not all the DIFs operate over the same scope and environment nor do they have to provide the same level of services.

In Figure 4, there are four devices: Node 1 and Node 2 are two end-hosts that are connected via two routers. A1 and A2 are two application processes willing to communicate, and the circles in the DIFs are called IPC Processes (IPCPs). IPCPs have the same structure that can join DIFs. DIF #2 spans the whole network, allowing packets to be routed and congestion-controlled from A1 to A2 via routers. There are also three DIFs #1 (could be assumed as the link layer) connecting devices together (performing mostly flow control). However, the structure variants of the DIFs are the same, and just the scope of the DIFs is different. This solves the problem of inventing new layers (as those presented by MPLS, VLAN, tunneling, etc.) and their deployment; the same layer can be customized via policies and instantiated to operate over different scopes.

In RINA, a Distributed Application is a set of two or more Application Processes (APs) that cooperate to perform some function. The set of these APs is called a Distributed Application Facility (DAF). DAFs use DIFs when IPC between the APs in DAF is not possible via shared memory.

In RINA, invariant parts (mechanisms) and variant parts (policies) are separated in different components of the architecture. This makes it possible to customize the behavior of a DIF to optimally operate in a certain environment with a set of policies for that environment instead of the traditional “one-size-fits-all” approach or having to re-implement mechanisms over and over again.

Figure 5 illustrates the data transfer modules inside IPCPs in a DIF. These modules show in each DIF, there is one (EFCP) sender and one (EFCP) receiver. The IPCP in the middle routes Protocol Data Units (PDUs) received from the left IPCP to the right one via its corresponding port. This scheme repeats at different DIFs, with the difference that it could be longer or as short as a point-to-point link without the routing IPCP. In [4], we evaluate the performance of a recursion of two layers of congestion controllers using a TCP Reno-like controller; we show that the recursion can improve throughput while decreasing queuing delay compared to an end-to-end TCP Reno and Split TCP (or PEP), where a connection is broken at routers.

The main difference between RINA and other stacks is that RINA recurses the same layer, called DIF numbered from 1 (e.g., 1-DIF, 2-DIF) as the lowest one, and (N)-DIF as the current one we are focusing on. At the lowest layer, shim DIF operates over the physical layer, but it has the deployment possibility of operating on other protocols such as UDP.

RINA preserves—and arguably improves upon—the deployment modularity of traditional layered architectures. In TCP/IP, changing one layer (e.g., replacing TCP with QUIC) requires careful consideration of cross-layer dependencies; in RINA, the separation of invariant mechanisms from variant policies means that modifying DIF behavior (e.g., switching congestion control algorithms or encryption ciphers) requires only policy reconfiguration, not code changes, and cannot inadvertently break adjacent DIFs since all DIFs expose identical APIs. Furthermore, RINA supports incremental deployment through “shim” DIFs that encapsulate RINA traffic over legacy protocols (e.g., UDP, Ethernet), allowing organizations to adopt RINA progressively without wholesale infrastructure replacement [60].

5.2. IPCP’s Mechanisms

A node joins a DIF through an IPC Process (IPCP), which is an instance of the same code handling IPC. IPCPs have the same structure consisting of the following mechanisms that operate at different timescales (ordered from faster to slower) discussed below.

5.2.1. Data Transfer

This is the most fundamental mechanism of the IPCP, and it is responsible for the actual movement of data. It involves a series of functions:

• Delimiting: This function encodes Service Data Units (SDUs) that arrive from the upper DIF within Protocol Data Units (PDUs).
• Error and Flow-Control Protocol (EFCP): This protocol ensures reliable data transmission using its two sub-protocols: Data Transfer Protocol (DTP) and Data Transfer Control Protocol (DTCP). DTP primarily concerns with the transmission and segmentation of data, while DTCP provides additional control functions, such as congestion control and error checking.
• Relaying and Multiplexing Task (RMT): This task performs routing of PDUs to output ports of the DIF or upwards. It utilizes the routing information provided by the layer management to determine the optimal path for data transmission.
• SDU Protection: This mechanism performs encryption, compression, error-code calculation, and Time-To-Live (TTL) setting.

5.2.2. Data Transfer Control

This mechanism supervises the data transmission process to ensure it runs smoothly and effectively. It includes several sub-components:

• Error Control: This component keeps track of any errors that may occur during data transmission. It uses a variety of error detection and correction techniques to maintain data integrity throughout the transmission process.
• Flow Control: This component manages the rate of data transmission ensuring that the receiver is not overwhelmed with data and can process incoming data effectively.
• Retransmission Control: This component monitors for lost or corrupted data packets. In the event of packet loss or corruption, it initiates a retransmission request, ensuring reliable data delivery.
• Congestion Control: This component monitors network congestion and implements measures to alleviate it. This can include reducing the data transmission rate.

5.2.3. Layer Management

The layer management mechanism includes:

• Resource Allocation: The Resource Allocator (RA) manages resource allocation and monitors the resources in the DIF by sharing information with other DIF IPC Processes and the performance of supporting DIFs.
• Routing: Routing performs the analysis of the information maintained by the Resource Information Base (RIB) to provide connectivity input to the creation of a forwarding function. The choice of routing algorithms in a particular DIF is a matter of policy.
• Security Coordination: Security coordination is responsible for implementing a consistent security profile for the IPC Process, coordinating all the security-related functions (authentication, access control, confidentiality, integrity) and also executing some of them (auditing, credential management).
• Namespace Management: The Name Space Manager (NSM) embedded in the DIF is responsible for mapping application names to IPC Process addresses. The NSM maintains a mapping between external application names and IPC Process addresses where there is the potential for a binding within the same processing system.
• Flow Allocation: The Flow Allocator is responsible for creating and managing an instance of IPC, i.e., a flow. The Flow Allocator-Instance (FAI) determines what policies will be utilized to provide the characteristics requested in the Allocate.
• Enrollment: The Enrollment process involves a new member joining the DIF. This process includes address assignment, information exchange about operational parameters, and updating the RIB with the latest information on routing, directory, resource allocation, etc. The new member then becomes a full member of the DIF.

5.3. Error and Flow-Control Protocol (EFCP)

EFCP is the only data transfer protocol in RINA, which is based on Richard Watson’s fundamental results on synchronization for reliable data transfer [61]. Its main functions are sequencing, flow control, and retransmission control. EFCP provides an inter-process communication service to upper processes that might be an (N + 1)-IPCP or and application process. The upper process is connected to (can write to/read from) the EFCP in the (N)-DIF via the (N)-port-id.

EFCP has two logical components operating at different time scales: (1) Data Transfer Protocol (DTP) that is the mandatory part of EFCP and includes tightly bound mechanisms, and (2) Data Transfer Control Protocol (DTCP), which include loosely bound mechanisms. DTP is instantiated every time a flow is created. It is roughly similar to the UDP protocol. However, depending on the QoS requirements, DTCP might be also instantiated to provide retransmission and flow control.

Watson’s result imply that the necessary and sufficient condition for synchronization to have a reliable data transfer is to set an upper bound on only these times: Maximum Packet Lifetime (MPL), maximum time to wait before sending an Ack, A, and the maximum time to exhaust retries, R [61]. This decouples port allocation and synchronization.

EFCP can be customized via several policies. A simple example is that the behavior of different TCP flavors can be imitated by writing different policies. The mechanisms operating on PDUs and policies are the same.

As shown in Figure 6, when a PDU is written to an (N)-port-id, the delimiting module, associated to the port, processes the PDU by possible fragmentation or concatenation. The result is passed to the EFCP instance associated to that port. As a result, generated PDUs are passed to the RMT for multiplexing. The RMT sends PDUs to one or more (N − 1) ports. When the RMT reads a PDU from an (N − 1)-port, if the PDU’s destination address is not in another node, it passes the PDU to the relevant EFCP instance for further processing. EFCP instances of (N)-DIF are managed by the module Flow Allocator (FA) in that DIF. FA can create a new EFCP instance, replace an old instance by a new one, or delete the instances.

5.4. Symmetry Properties of RINA

The Recursive InterNetwork Architecture exhibits fundamental symmetry properties that distinguish it from traditional network architectures and have significant implications for security. We identify three key symmetry characteristics.

5.4.1. Structural Self-Similarity

RINA’s most prominent symmetry property is its recursive self-similarity across network layers. Every DIF—whether operating at the link layer, network layer, or any intermediate scope—instantiates the same IPC Process (IPCP) code with identical internal structure (see Figure 4). This structural invariance means that the data transfer mechanisms (delimiting, EFCP, RMT, SDU protection), layer management functions (resource allocation, routing, enrollment), and security coordination modules are architecturally identical at every layer. Formally, if we denote the structural template of a DIF as $\mathcal{D}$, then for any $\left(N\right)$-DIF and $(N+1)$-DIF in the hierarchy,

$$\mathrm{Structure}\left({\mathcal{D}}_N\right)\cong \mathrm{Structure}\left({\mathcal{D}}_{N+1}\right).$$

(1)

This self-similarity ensures that security properties verified at one layer hold structurally at all layers, significantly reducing the verification burden compared to heterogeneous protocol stacks.

5.4.2. Mechanism Invariance and Policy Variance

RINA enforces a clear separation between mechanisms (invariant) and policies (variant). Mechanisms define what operations are performed (e.g., authentication, encryption, flow control), while policies define how these operations behave in a specific context. This separation creates a symmetric “skeleton” of capabilities across all DIFs, with asymmetric “flesh” determined by local policies. For IoT security, this means:

• Symmetric security mechanisms: Every DIF inherently supports authentication, access control, and SDU protection—there are no “security-free” layers as found in protocols like 6LoWPAN.
• Asymmetric security policies: A sensor-level DIF may employ lightweight encryption suitable for constrained devices, while a backbone DIF implements stronger cryptographic policies, without architectural modification.

5.4.3. Controlled Symmetry-Breaking for Security

While structural symmetry provides uniformity, RINA’s security model relies on intentional symmetry-breaking at specific boundaries:

• Address space asymmetry: Addresses are meaningful only within their DIF scope, creating an information asymmetry between internal members and external entities. An attacker outside a DIF cannot observe or predict internal addresses—a form of protective asymmetry.
• Authentication asymmetry: The enrollment process creates a binary asymmetry between authenticated (DIF member) and unauthenticated (non-member) entities. This asymmetry is fundamental to RINA’s access control model.
• Trust boundary asymmetry: Each DIF constitutes a trust domain with its own security policies. Cross-DIF communication requires explicit policy negotiation, preventing the implicit trust assumptions that plague flat network architectures.

This duality—symmetric structure enabling uniform security reasoning, combined with controlled asymmetry enabling context-specific protection—provides RINA with a principled foundation for addressing the heterogeneous security requirements of IoT ecosystems. The symmetry properties ensure that security mechanisms cannot be “forgotten” at any layer, while the asymmetry mechanisms ensure that attackers cannot leverage knowledge of one layer to compromise another.

5.4.4. Operational Implications of Symmetry

The preceding sections established RINA symmetry properties descriptively—what structural characteristics the architecture exhibits. We now address the operational question: What does symmetry enable that is impossible or impractical in architecturally asymmetric stacks like TCP/IP? This operationalization is essential for translating abstract symmetry properties into concrete security engineering practices.

We identify four operational capabilities that RINA’s symmetry uniquely enables below.

Op1: Verification Reuse Across Layers

In TCP/IP, each protocol layer implements distinct mechanisms with different semantics, state machines, and failure modes. Security verification must therefore be performed independently for each layer—IPsec requires different analysis techniques than TLS, which differs from application-layer OAuth. Formally, if $V(·)$ denotes the verification effort for a protocol, the total verification burden in TCP/IP scales as:

$$V_{\mathrm{TCP}/\mathrm{IP}}=\sum _{i=1}^{n}V\left(P_i\right)\mathrm{where}{P}_i\ne P_j\mathrm{for}i\ne j$$

(2)

In RINA, structural self-similarity means every DIF instantiates the same mechanisms. Security properties verified for one DIF hold by construction for all DIFs:

$$V_{\mathrm{RINA}}=V\left(\mathcal{D}\right)·(1+ϵ·n)\mathrm{where}ϵ\ll 1$$

(3)

The multiplicative factor $(1+ϵ·n)$ accounts for policy-specific verification, which is substantially cheaper than mechanism verification. This reduction is not merely theoretical: it directly enables formal methods that would be intractable across heterogeneous protocol stacks.

Op2: Uniform Security Control Placement

TCP/IP’s asymmetry creates ambiguity about where to deploy security controls. Should encryption occur at the network layer (IPsec), transport layer (TLS), or application layer? Should authentication be per-packet, per-connection, or per-session? These questions have no principled answers because each layer implements fundamentally different abstractions.

RINA’s symmetry provides a uniform placement rule: security controls (authentication, encryption, access control, monitoring) can be instantiated at any DIF using identical mechanisms, with scope determined by the DIF’s position in the hierarchy. This uniformity eliminates the “security placement problem” that plagues TCP/IP deployments and enables systematic defense-in-depth strategies.

Op3: Scope-Aligned Observability

Effective anomaly detection requires that monitoring scope aligns with communication scope. In TCP/IP, this alignment is impossible: network-layer monitors see IP packets but not TCP streams; transport-layer monitors see connections but not application semantics; application-layer monitors see requests but not routing behavior. Cross-layer attacks exploit these observability gaps.

RINA’s recursive structure guarantees that each DIF provides a complete observable unit: a DIF’s monitoring scope exactly matches its communication scope. Traffic entering a DIF is visible to that DIF’s security mechanisms; traffic between DIFs crosses explicit boundaries. This scope alignment is fundamental to the Learning-in-the-Middle approach validated in Section 9: detectors placed at DIF boundaries observe precisely the traffic relevant to their scope, eliminating the confounding cross-layer noise that degrades global detection approaches.

Op4: Composable Security Guarantees

In TCP/IP, security guarantees do not compose cleanly. TLS provides confidentiality for transport-layer payloads, but this guarantee says nothing about network-layer confidentiality (routing information remains exposed) or application-layer confidentiality (TLS terminates at proxies). Achieving end-to-end security requires careful, manual coordination across independently designed mechanisms.

RINA’s symmetry enables compositional security reasoning: if ${\mathrm{DIF}}_N$ provides security property $\varphi$ for its SDUs, and ${\mathrm{DIF}}_{N+1}$ provides $\varphi$ for its SDUs, then the composition provides $\varphi$ end-to-end because the mechanisms are identical and the interfaces are uniform. This compositionality is essential for IoT deployments that span heterogeneous trust domains.

These operational capabilities are not incidental benefits but direct consequences of architectural symmetry. We formalize this relationship as a novel design principle—the Symmetry Scoping principle—that constitutes a primary theoretical contribution of this paper and guides the analysis throughout:

This principle provides the evaluative framework for subsequent sections. In Section 7, we assess how each RINA security feature satisfies (or enables satisfaction of) the Symmetry Scoping principle. In Section 9, we empirically validate that scope-aligned detection (which operationalizes this principle) outperforms scope-ignoring alternatives.

6. Comprehensive Security Features of RINA

The Recursive InterNetwork Architecture (RINA) offers a novel approach to network design, aiming to address many of the security challenges inherent in traditional network architectures. By reimagining the conventional network stack and introducing a recursive layering model, RINA provides potential solutions to longstanding security weaknesses. In this section, we examine the various security features inherent in RINA and explore how they collectively contribute to a more secure and efficient network environment [13,57]. While the practical effectiveness of RINA in large-scale, real-world implementation remains an area for further research, and its theoretical security foundations merit careful consideration. The following discussion outlines key security features of RINA and their potential implications for network security.

6.1. Secure Distributed IPC Facilities (SD)

A fundamental security feature of RINA is that each Distributed IPC Facility (DIF) acts as a “securable container” [54]. Unlike traditional network architectures that focus on securing individual protocols, RINA secures entire layers. In practice, this means that all Protocol Data Units (PDUs) leaving an N-level DIF are protected by the Service Data Unit (SDU) Protection module. As a result, IPC Processes (IPCPs) in the lower-level $(N-1)$-DIF cannot inspect or alter the contents of the PDUs without appropriate authorization, depending on the policies of those DIFs. This protection can extend recursively down the stack, enhancing security at each layer.

Within the same DIF, however, IPCPs can inspect and process PDUs as necessary. This design facilitates operations such as performance enhancements or protocol conversions—common in scenarios like CoAP proxies—without obscuring the data or compromising security. By enabling authorized entities within a DIF to access necessary information while restricting access from outside entities, RINA effectively balances security with functional requirements.

Importantly, RINA requires that IPCPs undergo an enrollment process before joining a DIF. During enrollment, an IPCP’s access rights and credentials are validated, ensuring that only authorized entities can participate in the DIF. This mechanism prevents unauthorized outsiders from infiltrating the DIF and launching attacks from within.

Even in the event that an attacker compromises the enrollment process or if the DIF communication is not encrypted, RINA’s design includes safeguards to mitigate potential attacks. For example, RINA utilizes larger field lengths in its packet headers, resulting in a significantly larger namespace. This expansion makes it considerably more difficult for attackers to successfully guess connection information. Specifically, there are $2^{48}$ possible values for certain connection identifiers in RINA, compared to only $2^{29}$ possibilities in TCP during data transfer [54]. This vast increase in potential values substantially reduces the feasibility of successful guessing attacks, enhancing overall network security.

6.2. Hidden Addresses (HAs)

A fundamental security feature of RINA is its unique addressing scheme, where Inter-Process Communication Processes (IPCPs) within each Distributed IPC Facility (DIF) have their own local addresses. Unlike traditional IP addressing systems, where IP addresses are globally visible and can be targeted by malicious actors, RINA confines addresses within their respective DIFs, making them inaccessible to entities outside the DIF.

This “hidden addresses” feature mitigates major security concerns inherent in traditional IP-based networks. Public visibility of IP addresses exposes networks to threats such as Denial of Service (DoS) attacks, IP spoofing, and unauthorized access or data interception. By keeping addresses hidden within each DIF, RINA significantly reduces the attack surface, making it more difficult for malicious actors to target specific devices.

In the context of IoT, where networks comprise a vast number of interconnected devices with varying security capabilities, hidden addresses provide substantial security benefits. The recursive nature of RINA allows for highly scalable networks without compromising security, which is essential for large-scale IoT deployments. By confining address visibility to within a DIF, RINA enhances both security and scalability in IoT networks.

6.3. Decoupled Synchronization and Port Allocation (PA)

In traditional TCP/IP networks, synchronization and port allocation processes are coupled, introducing potential vulnerabilities. This coupling makes it easier for attackers to predict or ascertain the state of a connection and launch attacks such as SYN flood attacks—a type of Denial of Service (DoS) attack. In a SYN flood, an attacker sends numerous SYN requests to a target server without completing the TCP three-way handshake, overwhelming the server with half-open connections and exhausting its resources [62].

RINA addresses this vulnerability by decoupling synchronization from port allocation. In RINA, port allocation is independent of the synchronization process, making it substantially more challenging for attackers to predict or understand the state of a connection. This decoupling reduces the likelihood of intercepting a connection or launching successful attacks. By preventing attackers from easily identifying connection states, RINA effectively mitigates risks such as SYN floods and related vulnerabilities, enhancing overall network resilience.

6.4. Port-Independent Communication (PI)

In traditional network architectures, including the Internet Protocol (IP) suite, services are commonly associated with well-known port numbers. For example, web servers typically listen on port 80 for HTTP and port 443 for HTTPS. These well-known ports become prime targets for attackers, who can scan them for vulnerabilities or launch Denial-of-Service (DoS) attacks by overwhelming them with traffic.

RINA adopts a fundamentally different approach by decoupling services from specific port numbers. Instead of relying on well-known ports, applications in RINA request services using application names. This shift eliminates the concept of fixed standard ports for service identification, thereby significantly reducing the attack surface [57]. Attackers can no longer target specific ports because services do not reside on predictable, well-known port numbers.

6.5. Soft-State Connection Management (SS)

RINA diverges from traditional network architectures in its approach to connection management by adopting a soft-state mechanism, as proposed by Richard Watson [23]. Instead of using explicit control messages to establish or terminate connections, RINA relies on timers to manage connection states. After a period equal to twice the Maximum Packet Lifetime (2 × MPL), the receiver automatically deletes the connection state if no activity is detected.

This method provides several significant security benefits for IoT networks:

• Reduction in Connection Misuse Risks: The absence of explicit control messages for connection establishment and termination minimizes opportunities for malicious actors to exploit these messages to illegitimately establish, hijack, or disrupt connections. By eliminating such control signals, RINA reduces the avenues available for attack.
• Mitigation of Denial-of-Service Attacks: RINA’s soft-state management mitigates DoS attacks like SYN floods, which exploit control messages in traditional protocols like TCP. By removing reliance on these control messages, RINA decreases the likelihood of attackers successfully overwhelming the network with illegitimate connection requests.
• Efficient Resource Management: Automatic deletion of inactive connection states after 2 × MPL ensures that resources are not unnecessarily consumed by stale connections. This efficiency is crucial for IoT devices with limited computational resources, reducing the risk of resource exhaustion attacks where an attacker attempts to deplete system resources by establishing numerous connections.
• Enhanced Privacy: By not maintaining long-lived connection states, RINA makes it more challenging for adversaries to track and monitor user activities. Traditional networks with persistent connection states can inadvertently facilitate user profiling and surveillance. RINA’s transient connection states enhance privacy protections for users and devices within the network.

Overall, RINA’s soft-state connection management contributes to a more secure and efficient network environment, addressing several vulnerabilities inherent in traditional network architectures and providing tangible benefits for IoT deployments.

6.6. Connection Management Independent Authentication (IA)

In RINA, the authentication process is separate from connection management. Instead of performing authentication during connection establishment as in traditional network architectures, IPCPs in RINA are authenticated when they first enroll in a DIF.

This decoupling of authentication from connection management provides several significant security benefits for IoT networks. Firstly, by performing authentication at the enrollment stage, RINA ensures that only authenticated IPCPs can participate in the network. This measure reduces the risk of unauthorized access or impersonation attacks.

Secondly, traditional network architectures often couple authentication with connection management, exposing them to various attacks such as man-in-the-middle (MitM) attacks. By decoupling these processes, RINA minimizes the attack surface, making it more challenging for attackers to exploit the connection management process.

Moreover, the separation of authentication from connection management allows RINA to implement more robust access control mechanisms. This facilitates more granular control over who can access specific resources within the network, which is critical in IoT environments where devices with varying security capabilities are interconnected. Finally, handling authentication during enrollment helps prevent resource exhaustion attacks aimed at overwhelming the authentication process during connection establishment.

6.7. Variable Address Space (VA)

In traditional network architectures, addresses are usually fixed in size. For instance, IPv4 addresses are always 32 bits, and IPv6 addresses are 128 bits. These fixed-sized addresses can be predictable and potentially exploitable by attackers.

RINA, on the other hand, introduces the concept of variable address space. The size of addresses in a DIF can vary depending on the number of nodes in that DIF. Firstly, the variability in address size enhances unpredictability, making it difficult for attackers to predict the address space. This significantly complicates address-based attacks such as IP spoofing and reconnaissance [63].

Secondly, the variability also makes it harder for eavesdroppers to understand the network’s structure or track specific devices, thus enhancing network privacy. Furthermore, by adjusting the address size according to the number of nodes in a DIF, RINA ensures efficient use of the address space. This is particularly beneficial in IoT networks, where the number of devices can vary significantly. Lastly, the ability to vary address size provides RINA with superior scalability, ensuring that the network can effectively support both small-scale and large-scale IoT deployments.

6.8. RINA’s DAFs (DF)

In RINA, the application-layer component is encapsulated in what is known as the Distributed Application Facility (DAF). The DAF is responsible for providing services to applications and managing application-level communication. From a security standpoint, the DAF in RINA embodies the principle of end-to-end security. Unlike other networking architectures where security is often implemented as an afterthought, RINA incorporates security as an integral part of the DAF design. This means that applications using a DAF can rely on a built-in security model that protects their communication from eavesdropping, tampering, or message forgery.

When a DAF encrypts all communication, it indeed provides a robust layer of security for the application data, essentially rendering the information within the DIFs secure. This approach aligns with the principle of data protection at rest and in transit, one of the cornerstones of information security [64]. However, it is essential to understand that within a RINA network, each DIF still plays a crucial role in maintaining the overall system’s security. For instance, the top DIF might employ Payment Card Industry (PCI) encryption [65] to prevent traffic analysis, a form of network surveillance that threatens privacy. This layer-specific encryption is a proactive measure to counteract any potential security breaches.

In this context, one might argue that link-layer encryption becomes redundant, as it introduces additional overhead due to encryption and decryption at every hop. Moreover, the addresses used at this layer are typically not of interest to potential attackers, further questioning the necessity of link-layer encryption.

6.9. Common Distributed Application Protocol (CDAP)

A significant advantage of RINA’s architectural design is its emphasis on a unified application protocol and the flexibility of object models. Central to this design is the Common Distributed Application Protocol (CDAP), which provides a standardized framework for creating a wide range of distributed applications—most notably, the Distributed IPC Facility (DIF).

Unlike traditional network architectures that employ different application protocols for various services—often resulting in inconsistencies and increased complexity—RINA’s CDAP establishes a common language for all applications. This unification simplifies communication across diverse applications and eliminates the need for multiple, application-specific protocols such as the Constrained Application Protocol (CoAP). By reducing the complexity and overhead associated with maintaining numerous protocols, CDAP streamlines intercommunication between IoT devices and servers.

In the context of IoT, where devices are resource-constrained and interoperability is critical, CDAP’s unified approach offers substantial benefits. It reduces the protocol overhead on devices, simplifies application development, and enhances the efficiency of communication. This consistency not only aids in streamlining interactions between IoT devices and servers but also contributes to a more secure and manageable network environment by minimizing potential points of failure and vulnerabilities associated with multiple disparate protocols.

6.10. Multi-Layer Security (ML)

RINA adopts the “Divide and Conquer” principle through the use of Distributed IPC Facilities (DIFs) and recursion, enforcing security within smaller, more manageable scopes rather than attempting to secure an entire IoT network at once. This approach offers significant advantages that collectively enhance the security posture of IoT networks.

One primary benefit is the containment of attacks. By segmenting the network into DIFs, any potential compromise can be confined within a single DIF [33], ensuring that the integrity of the overall network remains largely intact even if some segments are breached. This isolation is critical in IoT environments where a vast number of diverse devices—with varying vulnerabilities—are interconnected [23].

The recursive nature of DIFs also contributes to enhanced scalability. It allows consistent security mechanisms to be applied across different scales, from small local networks to expansive global infrastructures. This scalability is crucial for IoT networks, which can range from a few devices in a home setting to millions within a city-wide deployment.

Moreover, securing smaller scopes is more manageable than attempting to secure a vast network as a whole. This granular approach enables more targeted security measures and facilitates easier monitoring and response to security incidents. Additionally, RINA’s multi-layer security allows for the implementation of tailored security policies. Each DIF can employ customized security measures suited to the specific needs and characteristics of the devices within it, resulting in a more fine-grained and effective approach compared to one-size-fits-all policies. This customization is particularly beneficial in heterogeneous IoT environments, where devices vary widely in capabilities and security requirements.

6.11. Communication Through a Common DIF (CC)

In RINA, a fundamental principle governs inter-application communication: two applications can exchange data only if they share a common Distributed IPC Facility (DIF). This paradigm significantly departs from traditional Internet protocols, where any two nodes with Internet connectivity can potentially initiate communication. If applications do not share a common DIF, they must either join an existing one or establish a new DIF to facilitate interaction.

Requiring a common DIF introduces a powerful mechanism to restrict unwanted communication within IoT ecosystems. By limiting interactions to applications within the same DIF, the risk of arbitrary node communication is significantly reduced, creating an inherent defense against malicious actors and compromised devices. This restriction serves as a foundational element for constructing secure IoT networks, enabling more effective enforcement of the principle of least privilege.

The common DIF requirement also enhances access control granularity. Network administrators can define precise communication boundaries, effectively controlling which devices interact within specific DIFs. This level of control is crucial in IoT environments where devices with varying security levels and operational requirements coexist. By segregating devices into appropriate DIFs, administrators can implement tailored security policies that align with the specific needs of different device groups or application domains.

From a defensive standpoint, RINA’s approach reduces the attack surface of IoT networks. By constraining communication to devices within a common DIF, attackers face significant barriers in reaching vulnerable devices outside their immediate DIF. This architectural feature provides an additional layer of protection for sensitive or critical IoT devices, complementing traditional security measures such as firewalls and intrusion detection systems.

Additionally, RINA’s DIF-based communication model enhances privacy in IoT ecosystems. Limiting device interactions to within-DIF boundaries improves the confidentiality of communication patterns and data exchanges. This inherent privacy is particularly valuable in IoT applications dealing with sensitive information, such as healthcare or industrial control systems, where data protection is paramount.

While the common DIF requirement may introduce operational complexities, especially in large-scale or heterogeneous IoT deployments, the security benefits it provides often outweigh these challenges. This approach aligns with the principle of security by design, embedding protective measures into the network architecture rather than treating them as afterthoughts.

6.12. Authentication (AU)

Authentication is a fundamental aspect of RINA’s security model, wherein every Inter-Process Communication Process (IPCP) must undergo verification before joining a Distributed IPC Facility (DIF). This process, along with access control measures, occurs during the enrollment phase and precedes any connection management activities. By requiring IPCPs to authenticate prior to DIF membership, RINA ensures that only verified entities can participate in network operations. This proactive approach significantly enhances access control within IoT ecosystems, effectively mitigating risks of unauthorized access and insider threats—concerns that are particularly acute in distributed IoT deployments.

Furthermore, RINA’s authentication mechanism inherently counteracts address spoofing attacks, a common vector for network intrusions. Since an IPCP must be authenticated and enrolled in a DIF before it can be addressed or communicate within that DIF, the architecture naturally prevents malicious entities from impersonating legitimate devices. This requirement establishes a robust barrier against such malicious activities, providing an additional layer of security without necessitating supplementary protocols or mechanisms.

By integrating authentication into the foundational operations of the network, RINA not only strengthens the security posture of IoT networks but also simplifies the security architecture. This built-in authentication reduces reliance on external security solutions, streamlines network management, and enhances overall trust in the system’s integrity.

6.13. Integrated Firewall Functionality (BF)

RINA adopts an innovative approach to network security by integrating firewall functionality directly into every router through security modules embedded within each IPC Process (IPCP). This architectural design enhances the security posture of IoT networks by providing a multi-layered defense mechanism against threats and safeguarding data integrity and confidentiality. By simplifying node types to three primary categories—end-nodes, border routers, and interior routers—RINA facilitates the implementation of consistent and effective security policies across the network. This streamlined architecture not only improves manageability but also reduces the overall attack surface, a critical advantage in complex IoT ecosystems.

Distributing security functionalities across all network routers represents a significant advancement over traditional centralized security models. By embedding security at the IPCP level, RINA mitigates the risks associated with single points of failure and balances the computational load required for security operations. This approach aligns with the inherently distributed nature of IoT networks, offering a more scalable and resilient security framework that can adapt to varying network conditions and demands.

Moreover, the granular control enabled by IPCP-level security modules allows for precise and customizable security policies across different network segments. This flexibility is particularly valuable in heterogeneous IoT environments, where devices with diverse capabilities and risk profiles coexist. Network administrators can implement tailored firewall rules and security measures based on the specific requirements and threat landscapes of distinct network zones, enhancing the overall robustness of the network’s security posture.

6.14. Programmable Distributed IPC Facilities (PD)

RINA introduces the concept of programmable Distributed IPC Facilities (DIFs), allowing for the dynamic integration of new functionalities—including security, privacy, and performance enhancements—as pluggable policies within existing mechanisms. This programmability offers significant flexibility in implementing security policies, which is crucial in the rapidly evolving landscape of IoT security where new threats and vulnerabilities emerge frequently [66].

The ability to program DIFs enables network administrators to swiftly develop and deploy new security measures in response to emerging threats without necessitating extensive architectural overhauls. This adaptability ensures that IoT networks can be updated promptly to counteract new attack vectors, enhancing overall resilience. By accommodating changes at the policy level, RINA allows for continuous improvement of security practices, aligning with the dynamic nature of IoT environments.

Moreover, RINA’s approach to programmable DIFs contributes to reducing functional redundancies in network protocols. Traditional networking often involves multiple overlapping protocols that increase complexity and may introduce security vulnerabilities [67]. By enabling new functionalities to be seamlessly integrated into existing mechanisms, RINA minimizes the proliferation of redundant protocols. This streamlining enhances operational efficiency and reduces the potential for vulnerabilities arising from unnecessary or outdated functionalities.

In the context of IoT, where resource constraints are a critical consideration, the efficiency gains from programmable DIFs have substantial implications for overall system security and performance. Resource-constrained devices benefit from reduced computational overhead and simplified protocol stacks, which can extend device lifespan and improve reliability. By optimizing resource utilization, RINA supports the deployment of robust security measures without overburdening the devices, thereby enhancing the security posture of IoT networks while maintaining performance standards.

6.15. Access Control (AC)

RINA integrates an access control mechanism within the Access Control module of each IPC Process (IPCP), utilizing the Common Distributed Application Protocol (CDAP) for signaling.

At its core, RINA’s access control mechanism ensures that every entity requesting resource access undergoes an authorization process, mitigating the risk of unauthorized access to network resources. By enforcing access control at the IPCP level, the architecture allows for highly specific, resource-centric policies. This fine-grained approach enables network administrators to implement differentiated strategies, aligning security measures with the sensitivity and criticality of each network asset. Such granularity is especially valuable in complex IoT deployments, where resources may have vastly different security requirements.

Moreover, by requiring authorization for each resource access attempt—even from authenticated entities—the system creates multiple checkpoints to detect and prevent misuse of access privileges, providing a defense against insider threats, a growing concern in IoT security. This multi-layered approach is crucial in IoT environments, where compromised devices or malicious insiders can significantly threaten network integrity.

Furthermore, using CDAP as the signaling protocol for access control enhances the security of this mechanism. CDAP incorporates built-in measures to ensure the integrity and authenticity of signaling messages, providing a secure foundation for access control operations.

6.16. Insiders Resistance (IR)

RINA introduces some measures to mitigate insider threats. RINA’s approach centers on the adoption of extended control field values, particularly in connection and Quality of Service (QoS) identifiers. The strategy is specifically engineered to bolster resistance against threats posed by entities that have already infiltrated the network or circumvented authentication processes, even in scenarios where cryptographic support may be compromised or absent.

A key feature of RINA’s insider threat resistance lies in its use of enlarged field lengths within packet structures. These extended fields can surpass the typical lengths found in traditional IP-based protocols such as TCP. This architectural decision serves a dual purpose: it not only enhances the overall security posture but also can increase the computational complexity required for potential attackers to successfully guess correct values [57]. In the context of IoT networks, where devices often have limited computational resources, this additional layer of security can prove crucial in deterring sophisticated attacks.

The implications of these extended field lengths are particularly evident in the realm of connection information security. As elucidated in [54], RINA’s field lengths offer an expansive $2^{48}$ possibilities for connection information. This represents a quantum leap in security when compared to the $2^{29}$ possibilities available in TCP during data transfer. The exponential increase in potential combinations significantly raises the bar for attackers attempting to guess or deduce connection information, rendering such attacks prohibitively resource-intensive and time-consuming.

6.17. QoS (QS)

RINA integrates Quality of Service (QoS) mechanisms directly into its connection establishment process. As outlined in [68], each connection in RINA is initiated only after the source entity presents its QoS requirements, typically including parameters such as maximum requested bandwidth. This integration of QoS into the core network architecture yields security benefits, particularly in the context of IoT networks where resource management and attack mitigation are critical concerns.

A primary security advantage of RINA’s QoS mechanism is its inherent resistance to Denial of Service (DoS) attacks. By enforcing QoS requirements at the connection level, RINA creates a defense layer against traffic-based attacks. If an entity attempts to deviate from its specified QoS parameters, such as by generating excessive network traffic in an attempt to congest the network, its packets can be promptly dropped at the first routing node. This capability acts as a preemptive DoS prevention measure, allowing the network to maintain service availability even in the face of potential volumetric attacks.

Furthermore, RINA’s QoS-centric approach facilitates effective traffic regulation across the network. By enforcing QoS requirements for each connection, RINA ensures that network resources are allocated fairly and efficiently. This regulation helps prevent network congestion and maintains overall network performance and reliability.

The enforcement of QoS requirements in RINA also serves as a foundation for sophisticated monitoring and detection mechanisms. As demonstrated in [69], deviations from specified QoS parameters can be leveraged as indicators of potential malicious activity. This approach enables the early detection and mitigation of security threats, allowing network administrators to identify and respond to anomalies before they escalate into full-fledged attacks.

6.18. Mobility (MO)

RINA inherently supports mobility through a design that allows any Inter-Process Communication Process (IPCP) within a Distributed IPC Facility (DIF) to seamlessly join or leave DIFs without compromising its identity in its original DIF. As described in [23], this solution requires only localized routing updates at lower DIFs, effectively managing mobility without introducing additional security vulnerabilities.

In traditional networking architectures, device mobility often introduces complex security challenges, including the maintenance of secure connections, authentication across network transitions, and prevention of session hijacking. RINA’s approach sidesteps many of these issues by maintaining consistent naming and addressing schemes regardless of a device’s physical location or network attachment point. This consistency eliminates the need for complex handover mechanisms and reduces the potential for security lapses during transitions.

Furthermore, RINA’s architecture extends beyond simple mobility to enhance multi-homing capabilities, as demonstrated by [70]. Multi-homing—the ability of a device to connect to multiple networks simultaneously—is increasingly critical in IoT deployments for ensuring reliability, load balancing, and seamless failover. RINA’s support for multi-homing not only improves network resilience but also offers security benefits by enabling devices to maintain multiple secure communication paths, reducing vulnerability to single points of failure or targeted attacks.

6.19. Resiliency (RS)

At the core of RINA’s resiliency is its unique design where each Distributed IPC Facility (DIF) independently and transparently performs multi-path routing, operating autonomously from other DIFs. This architectural feature yields a multi-faceted resiliency strategy that addresses several critical challenges in IoT network deployments.

A primary advantage of RINA’s design is the implementation of DIF-level resiliency. Each DIF is inherently capable of providing robust resiliency services to the upper DIFs in the network hierarchy. This layered approach tries to ensure that even in the event of path or segment failures, communication can persist through alternative routes. Furthermore, as [71] highlights, RINA’s architecture facilitates “transport over heterogeneous networks.” This capability is particularly crucial in the IoT domain, where devices often need to operate across diverse network types and technologies.

The decentralized nature of RINA’s routing mechanism, where each DIF operates independently, can mitigate the risk of single points of failure in targeted attacks that aim to disrupt specific network components or paths. RINA’s multi-path routing capability also facilitates effective load balancing across the network, as demonstrated in [72]. By distributing traffic across multiple paths, RINA not only optimizes network performance but can also enhance its resistance to congestion-based attacks.

Moreover, RINA’s resilience strategy enables rapid recovery from network failures. As [73] points out, the independent routing mechanism allows for swift rerouting of traffic through operational paths or DIFs in the event of failures. This capability minimizes service disruptions and maintains high availability, a crucial factor in mission-critical IoT applications where even brief outages can have significant consequences.

6.20. Performance Improvements (PR)

RINA not only can offer security features but also can introduce performance improvements that are particularly beneficial for IoT networks, as highlighted in [74]. These performance enhancements, while primarily designed to optimize network efficiency, have substantial indirect implications for IoT security, creating a synergistic relationship between performance and security in RINA-based systems.

A wealth of research studies (a comprehensive list of publications on RINA can be found at http://www.pouzinsociety.org/research/publications, accessed on 2 January 2026) and international projects (for more information, visit https://pouzinsociety.org/research-projects/, accessed on 2 January 2026) have consistently demonstrated RINA’s capability to markedly improve network performance metrics, particularly in terms of throughput and delay reduction. Notably, the work in [4] provides empirical evidence of these performance gains in various network scenarios.

The performance benefits of RINA are multifaceted and stem from its fundamental architectural design. By eliminating redundant protocol layers and optimizing data flow through its recursive structure, RINA can achieve a more streamlined and efficient network operation. The security implications of these performance improvements are substantial, albeit often indirect. Enhanced network performance contributes to IoT security. For example, by optimizing protocol operations and eliminating redundancies, RINA can reduce the overall complexity of the network stack. This simplification inherently reduces the attack surface, providing fewer entry points for potential security breaches.

The performance improvements offered by RINA enable more efficient scaling of IoT networks. This scalability is crucial for maintaining security in large-scale IoT deployments, where traditional architectures often struggle to maintain consistent security postures across vast numbers of devices.

6.21. Complexity Reduction (CR)

The simplification of network architecture introduced by RINA has profound implications for IoT network security [57]. In contrast to the current Internet—which relies on a multitude of protocols and complex configurations—RINA networks meet security requirements with a streamlined set of protocols, flows, and mechanisms. This reduction in the number of active networking components significantly eases the burden of network management and security enforcement.

With fewer protocols and mechanisms in operation, the network presents a smaller attack surface, reducing the number of potential vulnerabilities that attackers can exploit. This decrease in attack vectors enhances the overall security posture of the network. Additionally, the simplified network structure is inherently easier to monitor and manage, facilitating more efficient detection and response to potential security threats [67].

Furthermore, the reduced complexity enables the development of more straightforward and robust security policies [75]. In a less complex environment, these policies can be more comprehensive and are easier to implement and maintain. This simplicity not only improves the effectiveness of security measures but also reduces the likelihood of misconfigurations and errors that can lead to security breaches.

6.22. Arbitrary Arrangement (AA)

Distributed IPC Facilities (DIFs) in RINA can be configured and stacked in an arbitrary manner, providing flexibility for a wide range of operations while maintaining robust security measures [4]. This arbitrary arrangement allows for the customization of network topologies to meet specific needs and scenarios, enhancing the adaptability and scalability of network architectures. For example:

• Performance Enhancing Proxies (PEPs): In a satellite communication scenario, a DIF could be inserted between the ground station and the satellite to optimize protocol behavior for high-latency links, improving throughput without compromising end-to-end security.
• Multipath Routing: In a data center environment, multiple DIFs could be arranged to provide redundant paths between servers, enhancing both performance and reliability. Each path could implement different security policies based on the sensitivity of the data being transmitted.
• In-network Resource Sharing: In an IoT deployment, a DIF could be dedicated to managing shared resources among devices, such as a common data cache or processing unit, with access controlled through RINA’s built-in security mechanisms.

Moreover, the arbitrary arrangement of DIFs supports advanced security configurations. For instance:

• A lower-level DIF could be configured with stringent security policies, handling encryption and authentication for all traffic passing through it. This DIF would serve as a secure foundation for higher-level DIFs, effectively isolating critical security functions from general network operations.
• An intermediate DIF could be designed to manage fine-grained access control policies. This DIF would leverage RINA’s inherent authentication and authorization mechanisms to ensure that sensitive information is only accessible to authorized IPCPs, whether they represent personnel, devices, or applications.
• A higher-level DIF could be established for comprehensive network monitoring and security analytics. This DIF would collect and analyze data from lower DIFs, utilizing RINA’s recursive nature to detect anomalies and potential security breaches across the entire stack. It could implement advanced threat detection algorithms without interfering with the operations of other DIFs.
• Multiple DIFs at various levels could be arranged to implement a defense-in-depth strategy. For example, one DIF might focus on perimeter security, another on internal traffic segregation, and yet another on application-level security, all working in concert to provide layered protection.

This separation enhances the security posture of the network by limiting the scope of access to sensitive functions and reducing the potential attack surface. It also allows for the implementation of defense-in-depth strategies, where multiple layers of security can be deployed without interfering with the network’s core functionality.

7. Leveraging RINA for Enhanced IoT Security

7.1. Threat Model

This study adopts a network–centric threat model that is tailored to heterogeneous, resource-constrained Internet-of-Things (IoT) deployments operated over Recursive InterNetwork Architecture (RINA). It defines the assets, adversaries, assumptions, and security objectives against which the analysis in Section 7.2 is performed.

• Assets

• Confidentiality, integrity, and availability of user data carried in Service Data Units (SDUs) across all Distributed IPC Facilities (DIFs).
• Control-plane state of Flow Allocators, Enrollment processes, and policy modules that govern IPC Processes (IPCPs).
• Continuity of critical services (e.g., health monitoring, industrial control) that depend on timely delivery.

• Adversary capabilities

• External network attacker able to eavesdrop, inject, replay, or drop packets on links that cross administrative or DIF boundaries.
• Compromised IoT node with legitimate credentials for a single DIF, attempting privilege escalation or lateral movement.
• Malicious cloud/edge service that hosts application logic but not lower-layer IPCPs.

• Assumptions

• Physical tampering, side-channel attacks, and radio-jamming are out of scope. These attacks operate below the network architecture layer—physical tampering and side-channel attacks require hardware-level countermeasures (e.g., tamper-evident enclosures, constant-time cryptographic implementations), while radio-jamming demands physical-layer defenses (e.g., spread-spectrum, frequency hopping) that are orthogonal to protocol design.
• DIF enrollment relies on pre-provisioned public-key credentials (or an equivalent trust-anchor) and cannot be bypassed.
• Cryptographic primitives are perfect; attacks target protocol logic, policy misconfiguration, or resource exhaustion.

• Attacker goals

The adversary seeks to violate at least one of the classic CIA properties or to degrade Quality of Service below the thresholds required by the application domain.

• Security objectives

Following the above, RINA’s security mechanisms (Section 6) are evaluated with respect to:

O1 

Preventing unauthorized DIF enrollment and address spoofing.

O2 

Detecting and containing insider misbehaviour within a single DIF.

O3 

Maintaining availability under volumetric or state-exhaustion attacks.

O4 

Preserving end-to-end data confidentiality and integrity across heterogeneous DIF paths.

This threat model is aligned with the IoT adversary categorisations surveyed in [10,46] and provides the baseline for the feature-to-attack mapping in

Table 1. RINA features against IoT security challenges with mitigation classification.

Cat.	Challenge/Attack	Type	RINA Features and Rationale
Network Layer	Denial-of-Service	P, C	AU (outsiders cannot initiate flows), PI (no listening ports to flood), SS (stale connections auto-expire), QS (excess traffic dropped at first hop)
	Spoofing	P	HA (addresses hidden from external view), AU (identity verification required), PA (port allocation unpredictable)
	Sinkhole	C, D	CD (secure routing within DIF), ML (attack confined to single layer), BF (suspicious routing filtered)
	Wormhole	C, D	CD (DIF isolation limits tunnel endpoints), ML (cross-layer tunnels detectable), BF (anomalous paths filtered)
	Man-in-the-Middle	P, C	CD (encrypted DIF communication), AU (mutual authentication), PA (connection state unpredictable), IR (large field space resists guessing)
	Routing Info. Attacks	P, D	CD (routing tables protected within DIF), HA (topology obscured), AU (only members inject routes), BF (invalid updates filtered)
	Sybil	P, C	CD (identities scoped to DIF), AU (enrollment prevents fake identities)
	Unauthorized Access	P	AU (authentication required), AC (granular permissions), IA (auth precedes connection)
Middleware	SQL Injection	P, D	AU (authenticated database access), AC (query permissions enforced), PD (custom validation policies)
	Flooding	P, C	QS (bandwidth limits enforced per-flow, excess dropped)
	Signature Wrapping	P	AU (signature verification), DF (secure application protocol), CP (standardized message format)
	MITM (Middleware)	P	CD (channel encryption), AU (endpoint verification), HA (intermediaries cannot target endpoints)
	Cloud Malware Injection	P, D	AU (service authentication), AC (deployment permissions), PD (integrity policies), BF (malicious traffic filtered)
Application	Phishing	P	CD (communication restricted to DIF members), AU (sender verification), AC (interaction permissions)
	Malicious Virus/Worm	P, D	AU (code origin verified), BF (propagation traffic filtered)
	Malicious Scripts	P, D	DF (application-layer integrity), PD (custom script validation policies)
	Sniffing	P	CD (SDU protection encrypts payload)
	Brute Force/Dictionary	P	AU (lockout policies, strong credential requirements)
	False Data Injection	P, D	CD (integrity verification), DF (application-level data validation)
Properties	Privacy	P	CD (data confidentiality), ML (scope-limited exposure), CC (communication boundaries), PD (privacy policies)
	Authentication and Non-rep.	P	AU (identity binding at enrollment)
	Access Control	P	AC (CDAP-based authorization)
	Integrity and Confidentiality	P	CD (SDU protection), DF (end-to-end application security)
Architectural (Section 3)	Ch1: Network Stack	A	CD (security embedded per-layer), ML (consistent mechanisms), RS (multicast support), CR (reduced complexity)
	Ch2: Redundant Functionality	A	CD (single security mechanism), PD (policy customization), AA (no protocol duplication)
	Ch3: Address Space Mgmt.	A	ML (hierarchical scoping), HA (local addressing), VA (scalable allocation)
	Ch4: Security–Perf. Conflict	A	CD (security without breaking optimization), ML (layer-appropriate policies), AA (PEP-compatible)
	Ch5: Recurring Attacks	P, C	CD (structural defenses), AU (consistent authentication), IR (insider resistance)
	Ch6: Future Extensions	A	CP (extensible protocol), PD (adaptable policies), QS, MO, RS, PR
	Ch7: Cross-Domain Synergy	A	CD, DF (secure bridging), CP (common protocol), ML, CC, RS, AA

Mitigation Types: P = Prevent (stop attack); D = Detect (identify attack); C = Contain (limit blast radius); A = Architectural (design-level solution); Feature Codes: AA = Arbitrary Arrangement; AC = Access Control; AU = Authentication; BF = Built-in Firewall; CC = Common DIF Communication; CD = Secure DIFs; CP = CDAP Protocol; CR = Complexity Reduction; DF = DAF Security; HA = Hidden Addresses; IA = Independent Authentication; IR = Insider Resistance; ML = Multi-Layer Security; MO = Mobility; PA = Port Allocation; PD = Programmable DIFs; PI = Port Independence; PR = Performance; QS = QoS Enforcement; RS = Resiliency; SS = Soft-State; VA = Variable Addressing.

.

7.2. Attack Classification and Mitigation

The security landscape of IoT networks is complex and multifaceted, with threats spanning various layers of the network architecture. In Table 1, we present a comprehensive summary of the primary security challenges faced by IoT networks and demonstrate how RINA’s innovative features can effectively address these issues. Our analysis focuses on three key categories of attacks:

• Network Layer Attacks: These include threats that target the fundamental communication infrastructure of IoT systems, such as Denial of Service (DoS), routing attacks, and man-in-the-middle interventions.
• Middleware Layer Attacks: This category encompasses threats that exploit vulnerabilities in the software layer bridging IoT devices and applications, including data injection attacks and unauthorized access attempts.
• Application Layer Attacks: These attacks target the user-facing components of IoT systems, including phishing, malware infections, and data theft.

In addition to these attack categories, we also consider critical security properties that IoT systems must maintain, such as data integrity, confidentiality, and authentication. Furthermore, we address the architectural challenges inherent to IoT networks, as discussed in Section 2, which include issues like scalability, heterogeneity, and resource constraints.

Our classification and analysis of these security challenges draw from seminal works in the field, including the comprehensive studies in [10,46,76]. These sources provide in-depth examinations of how various attacks impact IoT networks and the unique vulnerabilities present in IoT ecosystems.

By mapping RINA’s features to these security challenges, we demonstrate the architecture’s potential to provide robust, multi-layered security for IoT networks. This approach not only addresses current threats but also offers a flexible framework capable of adapting to emerging security challenges in the rapidly evolving IoT landscape.

The subsequent sections present each category of attacks, discussing specific threats and evaluate RINA’s countermeasures.

Mapping Methodology. Table 1 maps RINA’s security features to IoT challenges based on how each feature contributes to defense. We classify mitigation types into four categories: Prevent (P)—the feature stops the attack from succeeding; Detect (D)—the feature enables identification of ongoing attacks; Contain (C)—the feature limits the blast radius or impact of successful attacks; and Architectural (A)—the feature addresses the challenge through fundamental design principles rather than reactive security measures. A feature may provide multiple mitigation types (e.g., authentication both prevents unauthorized access and contains insider threats to authenticated scope).

The attack–feature–mitigation mapping inevitably involves expert judgment, because different deployments can realize the same RINA mechanisms with different policy choices and telemetry availability. To mitigate subjectivity, we follow a rule-driven mapping protocol anchored in the attacker model and our security objectives (O1–O4): each row was first mapped to the objective(s) it threatens (impact lens), then to the RINA mechanism(s) it targets (causal lens), and finally to the minimal observable features required to detect/prevent/contain it (measurement lens). We additionally perform a consistency cross-check by verifying that (i) every objective O1–O4 is covered by at least one mapped attack instance, (ii) each attack instance maps to at least one concrete mechanism and one measurable feature set, and (iii) mappings remain stable when varying policy-dependent parameters (e.g., enrollment rules, addressing scope), with any ambiguities documented and resolved conservatively in favor of the attacker. This systematic mapping methodology operationalizes the Symmetry Scoping Principle (Section 5.4.4): we verify that each RINA feature satisfies the symmetry test (mechanism available at all layers) and scoping test (observable scope matches communication scope) before crediting it with mitigation capability.

7.2.1. Network Layer Attacks

Denial-of-Service: Denial-of-Service (DoS) and Distributed DoS (DDoS) attacks are historically considered major security threats and among the hardest security challenges. Although there are lots of proposed defense mechanisms against them such as packet filtering or intrusion detection systems, they make the headlines frequently and have become the hugest cyberattacks. In addition, they are improved and extended several times in different platforms, e.g., in the case of the Mirai attack [77].

Referring to the table, DoS attacks can be prevented/mitigated by Section 6.4, Section 6.5, Section 6.12 and Section 6.17. This means that the attacker cannot be an outsider (Section 6.12); they should join the DIF first or create a new one. Moreover, the preceding step in these attacks is flooding, but there is no listening port to be the target of such attacks (Section 6.4). In addition, since connections in RINA do not need to wait for explicit control messages to terminate (Section 6.5), flooding attacks and their impacts are mitigated. Even for an insider, there are mandatory QoS requirements that the flow should obey (Section 6.17), and any deviation from that by the sender can result in dropping packets at routers.

Spoofing: To defend against spoofing attacks such as IP (address) spoofing that exploits valid and authorized IP addresses, RINA hides internal DIF addresses (by Section 6.2) and decouples port allocation from the synchronization (by Section 6.3), and also Section 6.12 makes sure that no DIF outsider can attack.

Sinkhole: In sinkhole attacks, a compromised device tempts the others to use them in a data routing process. In addition to secure routing protocols (provided by Section 6.1, Section 6.10) useful to prevent these attacks, the capability of having firewall functionality in routers, i.e., Section 6.13 is helpful. This feature (Section 6.13) can similarly prevent wormhole attacks as well. In addition, since performing some attacks such as DoS is the prerequisite of the others to compromise a device, prevention of DoS attacks can be used to prevent sinkhole attacks. However, to keep the table simple, we mention the least features that can directly satisfy a security requirement, solve a challenge, or prevent an attack.

Wormhole: RINA’s defense against wormhole attacks leverages multiple architectural features. The secure DIFs (Section 6.1) create isolated network segments, making it difficult for attackers to establish tunnels between distant parts of the network. The multi-layer security approach (Section 6.10) ensures that even if a wormhole is established at one layer, it does not compromise the entire network stack. Additionally, the built-in firewall functionality (Section 6.13) in RINA routers can detect and filter out suspicious traffic patterns characteristic of wormhole attacks, such as packets appearing in unexpected locations with anomalous timing. This can reduce the feasibility and impact of wormhole attacks in RINA-based IoT networks.

Man-in-the-Middle: RINA’s secure DIFs (Section 6.1) create isolated communication environments, making it difficult for attackers to intercept traffic. The authentication mechanisms (Section 6.12) ensure that only legitimate entities can participate in communication. Additionally, the port allocation independent of synchronization (Section 6.3) and insider resistance features (Section 6.16) further complicate attempts to hijack or manipulate connections.

Routing Information Attacks: The combination of secure DIFs (Section 6.1), hidden addresses (Section 6.2), and authentication (Section 6.12) creates a robust defense against routing attacks. Malicious actors cannot easily inject false routing information or manipulate routing tables. The built-in firewall functionality (Section 6.13) adds an extra layer of protection by filtering suspicious routing updates.

Sybil Attacks: RINA’s authentication mechanisms (Section 6.12) can make it difficult for an attacker to create multiple fake identities. The secure DIFs (Section 6.1) further compartmentalize the network, limiting the potential impact of any compromised identities.

Unauthorized Access: The combination of authentication (Section 6.12), granular access control (Section 6.15), and authentication independent of connection management (Section 6.6) can create a multi-layered defense against unauthorized access attempts.

7.2.2. Middleware Layer Attacks

While RINA is primarily a network architecture, its design principles and security features have significant implications for middleware layer security. RINA’s approach to networking can inherently address vulnerabilities typically exploited at the middleware layer. We discuss the attacks at this layer below.

SQL Injection: This attack involves inserting malicious SQL code into application queries to manipulate or retrieve data from the database. RINA’s authentication (Section 6.12) and access control (Section 6.15) features can indirectly reduce exposure/limits blast radius for SQL injection attacks by ensuring that only authenticated and authorized entities can interact with the database layer, but does not replace secure coding practices. Additionally, RINA’s programmable DIFs (Section 6.14) allow for the implementation of custom security policies to detect and prevent SQL injection attempts.

Flooding: Similar to DoS attacks at the network layer, flooding at the middleware layer aims to overwhelm systems with excessive requests. RINA’s Quality of Service (Section 6.17) feature can help mitigate this by enforcing bandwidth limits and dropping packets that exceed predefined thresholds. The multi-layer security (ML) approach of RINA also helps contain the impact of flooding attacks to specific DIFs.

Signature Wrapping: This attack manipulates the structure of XML signatures to bypass authentication. RINA’s authentication (Section 6.12) and Distributed Application Facilities (DAFs) (Section 6.8) can provide robust protection against such attacks by implementing secure signature verification mechanisms. The Common Distributed Application Protocol (CDAP) used in RINA (Section 6.9) also helps standardize and secure communication, reducing vulnerabilities to signature wrapping attacks.

Man-in-the-Middle (MITM): At the middleware layer, MITM attacks intercept communication between components. RINA’s approach to secure communication within common DIFs (Section 6.1) and its authentication mechanisms (Section 6.12) can prevent unauthorized interception of data. The hidden addresses (Section 6.2) feature of RINA also makes it more difficult for attackers to identify and target specific communication channels.

Cloud Malware Injection: This attack involves injecting malicious services or virtual machines into the cloud infrastructure. RINA’s authentication (Section 6.12) and access control (Section 6.15) features, combined with its programmable DIFs (Section 6.14), can provide defenses against such attacks by ensuring that only verified and authorized services can be deployed. The built-in firewall capabilities (Section 6.13) of RINA can also help detect and prevent malware injection attempts.

7.2.3. Application Layer Attacks

RINA’s recursive nature and its concept of Distributed Application Facilities (DAFs) can bridge the gap between network and application layers. By providing a consistent security model across all layers, RINA can create an environment where application layer security is inherently strengthened by the underlying network architecture. This integration allows us to consider RINA’s features when discussing defenses against application layer attacks.

Phishing: This is a type of cyber attack where attackers deceive individuals into providing sensitive information, such as passwords or credit card numbers, by masquerading as a trustworthy entity in electronic communications. In RINA, this can be mitigated by authentication (Section 6.12) and authorization (Section 6.15) features.

Malicious Virus/Worm: This type of attack involves malicious software that can replicate itself and spread to other devices, causing harm or unauthorized access. In RINA, this can be addressed by authentication mechanisms (Section 6.12) and built-in firewall capabilities (Section 6.13).

Malicious Scripts: These attacks involve the execution of harmful scripts within web applications to exploit vulnerabilities, leading to unauthorized actions. In RINA, this can be mitigated through the secure handling of data within Distributed Application Facilities (DAFs) (Section 6.8) and the programmability of DIFs (Section 6.14) which allow for dynamic integration of security policies.

Sniffing: This attack involves intercepting data packets traveling over the network. By leveraging the confidentiality mechanisms provided by RINA’s SDU Protection module (Section 6.1), sensitive data can be encrypted, thus preventing unauthorized access and ensuring that intercepted data remains unintelligible to attackers.

Brute Force/Dictionary Attacks: These attacks aim to gain unauthorized access by systematically attempting various password combinations. RINA’s robust authentication feature (Section 6.12) can mitigate such attacks by enforcing strong password policies, incorporating multi-factor authentication, and employing account lockout mechanisms after a certain number of failed attempts, making it significantly more challenging for attackers to succeed.

False Data Injection: In this type of attack, an adversary inserts malicious data into the network to deceive or disrupt the system. RINA’s integrity features, enforced through the SDU Protection module (Section 6.1) and secure data handling within Distributed Application Facilities (DAFs) (Section 6.8), can ensure that any tampering with the data to be detected and mitigated. This includes the use of cryptographic checksums and secure data validation processes that protect against unauthorized data modifications.

7.3. Adhering to Foundational Security Principles

Privacy preservation in IoT has been identified as a critical concern by numerous studies [38,46]. RINA can address this challenge through several mechanisms. Firstly, RINA’s architecture allows for an expanded range of control field values, enabling more sophisticated and granular privacy tagging. This feature provides enhanced flexibility in managing privacy settings across diverse IoT devices and applications.

Furthermore, RINA’s programmable DIFs (Section 6.14) facilitate the implementation and enforcement of custom privacy-preserving access control policies. This capability allows for dynamic and context-aware privacy protection, adapting to the specific requirements of different IoT environments and use cases.

Another privacy-enhancing feature of RINA is its use of common DIFs with invisible addressing schemes (Section 6.11). This architectural element provides a framework for preserving anonymity and implementing comprehensive privacy policies. This obscures device addresses within these common DIFs.

Authentication is effectively addressed by RINA’s authentication feature Section 6.12. This feature ensures that each IPC Process (IPCP) undergoes an authentication process before being allowed to join a DIF. Access control is robustly managed by RINA’s access control feature Section 6.15. This feature enforces policies to regulate access permissions within the network, ensuring that only authorized entities can interact with specific resources.

As demonstrated in the table, RINA addresses both confidentiality and integrity through its SDU Protection module [57] (feature Section 6.11) and the Secure DAF feature Section 6.8. The SDU Protection module ensures that Service Data Units (SDUs) are protected, maintaining data confidentiality and integrity during transmission. Additionally, the Secure DAF feature provides robust security at the application layer, ensuring that all communication within a Distributed Application Facility (DAF) is secure, thus enhancing the overall confidentiality and integrity of the network.

7.4. Addressing IoT Architectural Challenges

7.4.1. Network Stack Challenge

Notably, RINA’s secure DIFs (Section 6.1) and divide-and-conquer approach (Section 6.10) can address the challenge Section 3.1 of IoT network stack vulnerabilities. For instance, the lack of authentication support in protocols like 6LoWPAN is resolved through RINA’s authentication mechanisms (Section 6.12) embedded within its security modules. This approach ensures that every layer of the IoT network stack has built-in security features, addressing the vulnerabilities common in current IoT protocols. This architectural approach exemplifies the Symmetry Scoping principle: security mechanisms (authentication, encryption, access control) are structurally identical across all DIFs, while policies vary according to each DIF’s scope and resource constraints.

Furthermore, RINA’s inherent support for transport layer multicast is facilitated by its resilience feature (Section 6.19), addressing a critical gap in many IoT communication protocols. Proxy compatibility, crucial for IoT environments with diverse devices and protocols, is ensured through the secure DIFs (Section 6.1). This is possible because each DIF maintains its own security and routing protocols, allowing for tailored solutions in different network segments.

The flexibility in arranging these DIFs, as demonstrated in [4], coupled with RINA’s reduced architectural complexity (Section 6.21), can provide a comprehensive solution to the security and efficiency requirements of IoT network stacks. Moreover, RINA’s programmable nature (Section 6.14) allows for the integration of new security features and protocols as IoT threats evolve, ensuring that the network stack remains robust against emerging vulnerabilities. This future-proofing aspect is crucial in the rapidly evolving landscape of IoT security.

7.4.2. Repeated Functionality

The RINA is addressed in Section 3.2 via the challenge of repeated functionality across layers and protocols, through its innovative architectural design. The solution lies in RINA’s fundamental principle of recursion, where Distributed IPC Facilities (DIFs) can be arbitrarily arranged and stacked (Section 6.22). This recursive structure, combined with the programmability of DIFs (Section 6.14), allows for customization via policies without the need for developing new protocols.

Critically, RINA can achieve this efficiency by instantiating the same IPC Process (IPCP) code recursively across different layers (as illustrated in Figure 3, all IPCPs are instantiated from the same base code). This approach not only eliminates redundancy but also enhances flexibility and scalability in IoT network design. The benefits of this approach in the IoT context are manifold. By using a single, recursively applied layer, RINA significantly reduces the complexity (Section 6.21) of the network stack, which is particularly beneficial for resource-constrained IoT devices. The consistent application of security policies across all layers (Section 6.10) eliminates security gaps that often arise from inconsistencies between different protocols in traditional architectures. RINA’s Common Distributed Application Protocol (CDAP) (Section 6.9) provides a standardized method for diverse IoT applications to communicate, addressing interoperability challenges in heterogeneous IoT environments. The elimination of redundant protocol implementations allows for more efficient use of limited resources in IoT devices, improving overall performance and battery life. Finally, the recursive nature of RINA’s architecture enables consistent networking principles to be applied from small-scale IoT deployments to large, complex systems without fundamental changes to the architecture, enhancing scalability.

7.4.3. Address Space Challenge

The RINA addressed in Section 3.3 via the challenge of managing global, public, and large address spaces, through its innovative approach to network segmentation. This solution is particularly relevant to the expanding IoT landscape, where the proliferation of devices demands a more scalable and secure addressing scheme.

By leveraging its Section 6.10 (Multi-Layer Security) feature, RINA creates a hierarchy of Distributed IPC Facilities (DIFs), effectively dividing the expansive network scope into smaller, more manageable units. This approach aligns well with the diverse and often segmented nature of IoT deployments, from smart homes to industrial IoT systems. Each DIF operates with its own Section 6.2 (Hidden Addresses) and Section 6.7 (Variable Address Space) features, providing dual benefits:

Address obfuscation through hidden addresses reduces the attack surface. The variable address space allows for optimized address allocation, adapting to the specific needs of different IoT segments. This flexibility is crucial in managing the vast number of devices in large-scale IoT deployments efficiently. RINA’s addressing scheme can accommodate the exponential growth in IoT devices without exhausting the address space or compromising security.

7.4.4. Security and Performance Conflict

RINA offers an elegant solution to Section 3.4, the challenge of balancing security and performance enhancement in IoT networks. This is achieved through several key architectural principles. RINA allows for the flexible arrangement and stacking of DIFs (Section 6.22). This adaptability enables network designers to optimize the architecture for specific IoT application requirements without compromising security. The recursive nature of RINA’s architecture enables the implementation of consistent security policies across different scales of IoT deployments, from small sensor networks to large-scale industrial IoT systems. The multi-layer security approach (Section 6.10) ensures that the security integrity of individual layers is maintained, even when DIFs are stacked or rearranged.

RINA’s architecture allows for the implementation of proxy functionality without interfering with the security measures of other layers. This is crucial for IoT environments where protocol translation and performance optimization are often necessary. Each Distributed IPC Facility (DIF) in RINA functions as an inherently “securable container” (Section 6.1). This design principle ensures that security measures are embedded at every layer of the network architecture.

In essence, RINA’s approach to IoT networking transcends the traditional trade-off between security and performance. By integrating security as a fundamental architectural component and providing the flexibility to optimize performance at various network layers, RINA offers a comprehensive solution to the complex challenges of modern IoT ecosystems. This balanced approach can ensure that as IoT networks grow in scale and complexity, they can maintain high levels of both security and performance, adapting to new requirements and threats without fundamental architectural changes.

7.4.5. Repeating Attacks Challenge

The RINA is addressed in Section 3.5 via the challenge of recurring and evolving attack patterns in IoT networks through a number of features. The programmable nature of RINA’s DIFs (Section 6.14) allows for the dynamic implementation and updating of security policies. This flexibility enables rapid response to newly discovered vulnerabilities or emerging attack vectors. RINA enforces an enrollment policy (Section 6.12) where all users and IPC Processes (IPCPs) must authenticate and register with secure Distributed IPC Facilities (DIFs) before gaining network access. This creates a robust first line of defense against external threats and significantly reduces the attack surface.

RINA’s architecture incorporates multiple security layers (Section 6.1 and Section 6.10), each capable of implementing its own security policies. This layered approach allows for the isolation of potential threats and prevents the propagation of attacks across the network. RINA’s design also includes sophisticated mechanisms for insider threat resistance (Section 6.16). These features make it significantly more challenging for attackers who have already gained access to the network to further exploit or compromise the system.

7.4.6. Future Trend Challenge

RINA demonstrates adaptability in addressing the challenge of future extensions and emerging technologies in IoT (Section 3.6). This forward-looking capability is rooted in RINA’s inherent programmability (Section 6.14), a core feature of its architecture. RINA’s approach to future-proofing IoT networks is multi-faceted and aligns well with emerging trends:

AI-Driven Security: RINA’s programmable DIFs (Section 6.14) can accommodate AI and machine learning algorithms for predictive security measures. This flexibility allows for the integration of advanced threat detection and mitigation strategies, addressing the emerging challenge of AI-driven attacks in IoT environments.

Blockchain Integration: While RINA does not inherently include Blockchain technology, its architecture allows for the integration of distributed ledger technologies. This can be achieved through custom policies within DIFs, enabling secure and decentralized data management for IoT devices.

Edge Computing Security: RINA’s multi-layer security (Section 6.10) and ability to create secure, localized DIFs align perfectly with the shift towards edge computing in IoT. This allows for secure data processing at the network edge, reducing latency while maintaining robust security measures.

Ultra-Low Latency Applications: RINA’s Quality of Service (Section 6.17) mechanisms can be fine-tuned to support emerging ultra-low latency applications like the Tactile Internet. The architecture’s ability to optimize communication paths and reduce protocol overhead is particularly beneficial for time-critical IoT applications.

Massive IoT Scalability: RINA’s recursive nature and addressing scheme (VA) provide a scalable solution for managing billions of IoT endpoints. This addresses the challenge of massive IoT deployments without compromising security or performance.

Cognitive IoT: RINA’s programmable DIFs (Section 6.14) and layered security approach (Section 6.10) can support the evolution of more intelligent and autonomous IoT devices. The architecture can accommodate complex decision-making processes while ensuring the integrity and security of these cognitive functions.

Enhanced Mobility Support: RINA’s built-in support for mobility (Section 6.18) is particularly relevant for emerging IoT applications that require seamless connectivity across different network environments, such as connected vehicles or mobile health devices.

Resilient Network Architecture: RINA’s inherent network resiliency (Section 6.19) features are crucial for maintaining the integrity and availability of IoT services, especially in critical infrastructure applications where network failures could have severe consequences.

Furthermore, RINA’s architecture can support the convergence of IoT with other emerging technologies like 5G/6G, software-defined networking (SDN), and network function virtualization (NFV). The Common Distributed Application Protocol (CDAP) used in RINA provides a standardized method for diverse IoT applications to communicate, addressing interoperability challenges in heterogeneous IoT environments. The flexibility of RINA positions it as a potential future-proof architecture, capable of addressing the rapidly advancing IoT landscape while maintaining robust security measures.

7.4.7. RINA’s Resilience to Adversarial ML Attacks

As machine learning (ML) becomes increasingly integrated into IoT systems, the threat of adversarial ML attacks grows. RINA’s architecture offers several inherent features that can enhance resilience against such attacks:

Layered Defense: RINA’s multi-layer security approach (Section 6.10) creates multiple barriers against adversarial attacks. Each DIF can implement its own ML-based security measures, making it more challenging for attackers to craft adversarial examples that can penetrate all layers.

Dynamic Model Deployment: The programmable nature of DIFs (Section 6.14) allows for the dynamic deployment and updating of ML models. This flexibility enables rapid response to newly discovered adversarial techniques, allowing defenders to quickly update or replace vulnerable models.

Diverse Model Ecosystem: RINA’s architecture supports the deployment of diverse ML models across different DIFs. This diversity can create an ensemble effect, where different models may be resistant to different types of adversarial examples, increasing overall system robustness.

Contextual Data Processing: Each DIF in RINA can process data within its specific context. This contextual awareness can help in detecting out-of-distribution inputs, which are often characteristic of adversarial examples.

Secure Data Flow: RINA’s secure DIFs (Section 6.1) ensure that data used for ML model training and inference are protected from tampering, reducing the risk of data poisoning attacks.

Isolation of ML Components: The ability to isolate ML components within specific DIFs limits the potential impact of a successful adversarial attack, containing it within a single layer rather than compromising the entire system.

Enhanced Monitoring: RINA’s architecture allows for comprehensive monitoring across all layers. This can facilitate the early detection of anomalies that might indicate an adversarial attack in progress.

While these features provide a foundation for resisting adversarial ML attacks, it is important to note that the field of adversarial ML is rapidly evolving. Future research could focus on developing RINA-specific defenses against adversarial examples, leveraging the architecture’s characteristics to create novel protection mechanisms. For instance, one could explore the development of cross-layer adversarial detection systems that leverage the hierarchical nature of RINA’s DIFs. Another promising direction is the investigation of how RINA’s programmable policies can be used to implement adaptive defenses that evolve in response to observed adversarial patterns.

In conclusion, while RINA does not inherently solve all challenges posed by adversarial ML, its flexible architecture can provide a framework for implementing and evolving defenses against these sophisticated attacks in IoT environments.

7.4.8. Domain Synergy Challenge

RINA offers a solution to the challenge of cross-domain synergy (Section 3.7) in IoT environments. This is achieved through a combination of its key architectural features. The recursive nature of RINA (Section 6.10) allows for seamless integration of diverse IoT domains, while the ability to arbitrarily arrange DIFs (Section 6.22) provides the flexibility needed to accommodate varying domain-specific requirements.

Central to this solution are RINA’s secure (Section 6.1) and common (Section 6.11) DIFs, which serve as universal interfaces between different domains. These DIFs create a standardized yet secure communication layer that bridges disparate IoT ecosystems without compromising the individual security policies or performance requirements of each domain. Importantly, RINA’s approach to cross-domain synergy maintains consistent security and performance levels across all integrated domains. This is facilitated by RINA’s inherent resilience (Section 6.19), which ensures operation regardless of the underlying network infrastructure or the specific characteristics of individual IoT domains.

7.5. Attack Case Study: Mirai Botnet Attack

Here, we further discuss RINA and how in practice, it could have mitigated some famous attacks if used as the network architecture. The Mirai botnet, first identified in 2016, stands as a pivotal moment in cybersecurity history, particularly concerning the Internet of Things (IoT). By exploiting widespread vulnerabilities in IoT devices—such as IP cameras, digital video recorders (DVRs), and home routers—Mirai assembled a massive botnet used to launch unprecedented distributed denial-of-service (DDoS) attacks. This event underscored the critical security deficiencies prevalent in IoT ecosystems and highlighted the potential for large-scale internet disruption.

7.5.1. Attack Vector

Mirai’s attack vector capitalized on the proliferation of IoT devices with default or hard-coded credentials. The malware employed an automated scanning mechanism to identify vulnerable devices across the internet. Key aspects of its attack methodology include:

• Automated Scanning and Infection: Mirai continuously scanned IP address spaces to detect open Telnet ports (TCP/23 and TCP/2323). Upon finding an accessible device, it attempted to log in using a list of 61 common default username and password combinations hard-coded into the malware.
• Exploitation of Default Credentials: Many IoT devices shipped with factory-default login credentials that users rarely changed. This oversight provided an easy entry point for Mirai to gain unauthorized access.
• Memory-Resident Payload: The malware resided in the device’s volatile memory, making it resilient to detection but also meaning that a simple reboot could remove it. However, due to persistent vulnerabilities, devices often became reinfected shortly after rebooting.
• Command and Control (C&C) Infrastructure: Infected devices reported back to centralized C&C servers, awaiting instructions to participate in coordinated DDoS attacks.

At its zenith, the Mirai botnet compromised over 600,000 devices. It was responsible for some of the largest DDoS attacks recorded at the time, exceeding 1 terabit per second (Tbps). The Mirai attack demonstrated how easily unsecured IoT devices could be weaponized, causing widespread disruption and highlighting the urgent need for improved security measures in IoT deployments.

7.5.2. How RINA Could Have Prevented the Attack

The Recursive InterNetwork Architecture (RINA) offers several intrinsic features that could have mitigated, if not entirely prevented, the Mirai botnet attack:

• Authentication and Access Control: RINA mandates mutual authentication before any communication is established between devices. Each interaction requires entities to verify each other’s identities using robust authentication protocols. This approach eliminates the reliance on weak or default credentials, as unauthorized devices cannot participate in the network without proper authentication.
• Fine-Grained Network Isolation through DIFs: RINA introduces Distributed IPC Facilities (DIFs), which are layers providing Inter-Process Communication (IPC) services with specific policies and mechanisms. By organizing devices into separate DIFs based on trust levels, functionality, or security requirements, RINA prevents unauthorized lateral movement. Even if a device were compromised, the malware’s ability to spread would be confined within that DIF, limiting the overall impact.
• Dynamic Addressing and Naming: Unlike the static and globally routable IP addresses exploited by Mirai, RINA uses dynamic addressing within each DIF. Addresses are not exposed globally and are only meaningful within their specific context. This obscurity makes it significantly more challenging for attackers to discover and target devices en masse, as there is no uniform addressing scheme to exploit.
• Policy-Based Flow Management and Traffic Monitoring: RINA’s architecture allows for customizable flow management policies at each DIF. Network administrators can implement policies to monitor for abnormal traffic patterns, such as the rapid scanning and high-volume traffic characteristic of botnet activity. Suspicious flows can be throttled, redirected, or terminated, thereby mitigating the propagation of malware and participation in DDoS attacks.
• Secure Enrollment and Bootstrapping: The enrollment process in RINA ensures that devices are authenticated and authorized before joining a DIF. This process can include checks for up-to-date firmware, compliance with security policies, and validation of cryptographic credentials. Such rigorous vetting prevents compromised or non-compliant devices from integrating into the network.
• Simplified and Consistent Security Policies: RINA’s recursive nature allows for consistent application of security policies across all layers of the network. This uniformity reduces complexity and the likelihood of configuration errors that could introduce vulnerabilities. Administrators can define security policies once and have them propagate throughout the network hierarchy.
• Resilience to Single Points of Failure: RINA’s architecture avoids reliance on centralized servers or services that could become focal points for attacks. Distributed management and control can reduce the risk of widespread disruption resulting from the compromise of a single component.

7.6. Comparative Analysis of RINA and Other IoT Security Solutions

To strengthen the argument for RINA’s adoption, it is crucial to compare it explicitly with other proposed IoT security solutions.

Table 2. Comparative analysis of IoT security architectures. RINA’s advantages stem from architectural symmetry (Section 5.4); deployment maturity reflects adoption status, not technical merit.

Criterion	RINA	TCP/IP	SDN	Blockchain	Edge Comp.	ICN
Security Integration	Embedded	Layered add-on	Overlay	Data-centric	Requires add-on	Content-native
Architectural Flexibility	High	Low	High	Low	Medium	Medium
Massive IoT Scalability	High	Limited	Medium †	Low	Medium	High
Resource Efficiency	High	Medium	Low ‡	Low	Variable	Medium
Implementation Complexity	Low	High	Medium	High	Medium	Medium
End-to-End Security	Consistent	Layer gaps	Controller-dep.	Strong (data)	Interface gaps	Content only
Deployment Maturity	Emerging	Ubiquitous	Established	Growing	Mainstream	Research

^† Controller bottleneck at scale. ^‡ Requires dedicated controller hardware; RINA features: Security (Section 6.1), Flexibility (Section 6.14), Scalability (Section 6.7), Efficiency (Section 6.20), Complexity (Section 6.21).

provides a comprehensive comparison between RINA and five prominent approaches to IoT security: traditional TCP/IP-based solutions, Software-Defined Networking (SDN) [78], blockchain-based solutions [79], edge computing security solutions [80], and ICN.

RINA represents a fundamental rethinking of network architecture from the ground up, similar to how ICN challenges the host-centric model of TCP/IP. SDN, Blockchain, and Edge Computing, while innovative, do not propose such fundamental changes to the networking paradigm itself. Our research in this paper aims to explore alternatives to the current Internet architecture for IoT, making RINA and ICN more relevant to our core discussion than complementary technologies like SDN, Blockchain, or edge computing. Nevertheless, we acknowledge the importance of these other approaches and include them in our comparative analysis to provide a comprehensive overview of the current IoT security landscape. The comparison in Table 2 highlights several key advantages of RINA over these alternatives.

Integrated Security: Unlike other solutions that often add security as an overlay or separate layer, RINA embeds security at each layer of its architecture (Section 6.1), providing comprehensive protection.

Flexibility and Adaptability: RINA’s programmable DIFs (Section 6.14) offer superior flexibility compared to traditional solutions and even SDN, allowing for customized security policies tailored to specific IoT application needs. This flexibility surpasses that of traditional solutions and even SDN, which, while programmable, often require significant infrastructure changes.

Scalability: RINA’s recursive structure and variable address space (Section 6.7) provide excellent scalability, addressing a critical requirement for large-scale IoT deployments that other solutions often struggle with.

Efficiency: By reducing redundancy and integrating security seamlessly, RINA offers improved network efficiency (Section 6.20) compared to solutions that add substantial overhead.

Complexity Management: While other solutions can introduce additional complexity, especially in large-scale deployments, RINA’s approach potentially reduces overall network complexity (Section 6.21). Simplifying the network stack makes management and security enforcement more straightforward.

Resource Efficiency: RINA’s design is more suitable for resource-constrained IoT devices compared to computationally intensive solutions like Blockchain. This suitability is crucial for IoT environments where devices often have limited processing capabilities.

Consistent End-to-End Security: RINA maintains consistent security across all network segments, addressing potential vulnerabilities that can arise in other approaches, particularly at interfaces between different network domains. This consistency ensures that security policies are uniformly applied, enhancing the overall security posture of the IoT network.

While each approach offers valuable contributions to IoT security, RINA’s integrated, flexible, and scalable architecture provides a comprehensive framework that has the potential to address many limitations of existing solutions. Its ability to adapt to diverse IoT environments while maintaining strong security principles positions RINA as a promising candidate for next-generation IoT security architectures.

8. Employing RINA in IoT—A Qualitative Use Case Study

To better understand the practical implications of RINA in IoT networks, we consider several diverse use cases that demonstrate how RINA can be applied across various scenarios. We begin with a smart home environment where IoT devices can run a RINA stack, showcasing its application in consumer-oriented settings. We then explore a healthcare scenario where devices use their own legacy protocols, illustrating RINA’s adaptability to existing systems. The paper also examines RINA’s capability for efficient and secure multicast communication, a critical feature for many IoT applications. Furthermore, we delve into cognitive security in autonomous vehicle networks, demonstrating RINA’s potential in complex, decision-making IoT systems. Finally, we investigate RINA’s application in secure edge computing within a smart manufacturing context, highlighting its relevance to industrial IoT. These varied use cases allow us to explore RINA’s versatility and effectiveness across different IoT domains, from consumer applications to industrial settings, and from simple data transmission to complex, security-critical scenarios.

Note on Use Case Implementation. The preceding use cases represent architectural analyses demonstrating how RINA’s features could be applied to various IoT scenarios. They are design illustrations rather than implemented systems. Readers interested in prototyping these scenarios should consult the RINA reference implementations: the IRATI stack (https://github.com/IRATI/stack, accessed on 2 January 2026) for research environments.

8.1. Home

The smart home scenario is an ideal testbed for the application of RINA in the IoT context. In this setting, we consider a variety of smart devices, such as temperature sensors, smart light bulbs, home security cameras, and home automation systems, all provided by different vendors. The integration of these systems can pose a challenge due to the wide range of security and operational requirements, and the variety of legacy protocols involved.

The application of RINA in this context can provide a unified networking framework to alleviate these challenges. As shown in Figure 7, we consider a common IoT network topology where wireless nodes, such as smart home devices, connect to an access point over a wireless protocol. In this case, the communication between the two devices (with IPCPs C1 and C2) requires a common DIF. Furthermore, the wireless node must also belong to another DIF that spans over the network to reach the servers in the cloud.

In this scenario, the communication path traverses a network segment (between C3 and C5) that is not a member of the top DIF. This implies that packets between B2 and B3 are (or can be) inaccessible to Router1. This design provides an additional layer of security and privacy, as the data from the IoT devices in the home cannot be accessed or tampered with by unauthorized entities.

Moreover, this architecture allows for each segment of the path to customize its congestion control policy. For instance, the congestion controller between C3 and C5 can be tailored to the specific characteristics of that segment, while the congestion controller between C1 and C2 takes into account the conditions of the wireless link. This adaptability can enhance the efficiency and reliability of data transfers, which are key for seamless operation in a smart home environment.

Furthermore, each path segment can implement its own SDU protection policy, thereby enhancing the overall security of the network. At the same time, the node at B2 can perform any necessary operations on the PDU sent from B1 to reach B3. This feature ensures interoperability and smooth communication between IoT devices and the cloud servers.

8.2. Health

The healthcare sector represents another significant area where IoT has been making a considerable impact, particularly in the field of patient monitoring and care. Wearable IoT devices have been instrumental in monitoring the health and behaviors of specific risk groups, such as elderly individuals, people recovering from illnesses, disabled individuals, and children. These devices aim to reduce risks, prevent accidents, issue preventive warnings, initiate corrective measures, or request assistance from trusted caregivers when necessary.

Figure 8 depicts a sample topology of a health IoT device that does not inherently support RINA. As suggested in [81], these legacy IoT devices can be incorporated into a RINA network using a special type of gateway called an IoT sub-manager. The IoT sub-manager’s primary purpose is to translate a legacy (non-RINA) IoT protocol to a common RINA protocol—CDAP. CDAP achieves commonality by focusing on operations such as read/write, create/delete, and start/stop on object models. This arrangement allows for seamless integration of legacy devices while maintaining the benefits of the RINA architecture.

The network segment from the IoT sub-manager to the servers is identical to the previous scenario; it routes packets seamlessly while taking into account their security, eliminating the need for an end-to-end connection. The IoT sub-manager plays a critical role in this architecture as it is responsible for translating the legacy protocol/packets from the IoT device into a format that can be understood by the RINA network. This translation operation is performed by the Trl module within the IoT sub-manager.

Once translated, the data are passed to IPC process A1, where it is treated in the same manner as data presented to A1 in Figure 7. This arrangement implies that the IoT sub-manager should be a trusted device due to its critical role in data translation and transmission.

An important consideration when using IoT sub-managers is managing the data send rate of the IoT device. If the IoT device transmits data faster than the RINA network segment can handle, creating a bottleneck, the Trl module within the IoT sub-manager should be able to push back or slow down the app. This capability adds to the versatility of the translation function performed by the Trl module and ensures efficient and reliable data transmission in the health IoT network.

The incorporation of legacy IoT devices into a RINA network using IoT sub-managers can significantly enhance the security, reliability, and efficiency of health IoT networks. This arrangement allows for the secure and efficient monitoring of high-risk individuals, leading to improved patient care and outcomes.

8.3. Secure Multicast

Secure multicast forms an integral part of IoT networking where one source node often needs to send data to multiple destination nodes. Such a feature becomes crucial in scenarios like home automation, where a single command needs to be dispatched to multiple devices, or in healthcare, where patient data may need to be shared with multiple healthcare providers simultaneously [82].

In the context of RINA, secure multicast can be implemented effortlessly and efficiently, eliminating the need for the complex security measures described for multicast CoAP applications in [82].

In RINA, security is an integral part of the architecture, not an add-on. The security in RINA is based on the principle of “only talk to known and authenticated IPC processes”. This means that any IPCP, including those involved in multicast communication, must be authenticated before it can join a DIF. This authentication process ensures that only authorized processes can participate in the multicast communication, providing a high level of security. This also contrasts with the CoAP approach, which requires the establishment of a group key and a set of pairwise keys for secure multicast communication, a process that can be complex and resource-intensive.

Refer to Figure 7 and Figure 8, where the goal is to transmit data from an IoT device to several servers. This does not necessitate multiple separate connections from the IoT device to each server. Instead, RINA enables the use of a multicast destination address within DIF B. The process starts with IPCP B1 receiving a packet from the IoT device and sending it to B2. At this stage, the RMT (Relaying and Multiplexing Task) module within B2 comes into play. The RMT module examines the destination port(s) and identifies that there are multiple servers connected to Access1 via Router1, each having a distinct DIF with C3, C4, and C5.

Upon this identification, the RMT in B2 replicates the packet and dispatches it to all the identified ports. As a result, IPCP C5 in each of the servers receives a copy of the packet and forwards it to the higher layers in the stack. This multicast mechanism ensures the security of the packets within DIF B is maintained, as each packet remains within the boundaries of a single DIF, thus preserving the inherent security of the communication.

Below is a case study example demonstrating how RINA can address cognitive security in a practical IoT scenario.

8.4. Cognitive Security in Autonomous Vehicle Networks

Consider an urban environment with a network of autonomous vehicles. These vehicles constantly make critical decisions based on real-time data from various sources, including onboard sensors, other vehicles, and city infrastructure. Ensuring the integrity and security of these cognitive processes is crucial for safety and efficiency.

In this scenario, RINA can address cognitive security as follows:

Multi-layer Cognitive Processing: RINA’s architecture allows the creation of multiple DIFs, each handling different aspects of the vehicle’s cognitive processes:

• Local Cognition DIF: Manages onboard sensor data and immediate decision-making.
• Vehicle-to-Vehicle (V2V) DIF: Handles secure communication and decision-making between nearby vehicles.
• Vehicle-to-Infrastructure (V2I) DIF: Manages interactions with city infrastructure and broader traffic management systems.

Secure Data Flows: Each DIF uses RINA’s SDU Protection (Section 6.1) to ensure the integrity and confidentiality of data crucial for cognitive processes. For instance, the V2V DIF securely exchanges intention data between vehicles, preventing malicious interference that could lead to collisions.

Adaptive Security Policies: Using RINA’s programmable DIFs (Section 6.14), security policies can adapt to different cognitive states. For example, in high-risk scenarios (e.g., high-speed or congested areas), stricter authentication and data validation policies can be automatically enforced.

Contextual Decision Validation: The multi-layer structure (Section 6.10) allows for decision validation across different contexts. A decision made in the Local Cognition DIF can be cross-validated with information from the V2V and V2I DIFs, enhancing the overall security of the cognitive process.

Isolation of Critical Functions: RINA’s ability to create separate DIFs allows for the isolation of critical cognitive functions. For instance, emergency override systems can operate in a highly secured DIF, protected from potential compromises in other parts of the system.

Distributed Cognition: Complex cognitive tasks can be securely distributed across multiple vehicles or infrastructure nodes. RINA’s architecture ensures that this distributed processing remains secure, leveraging features like hidden addresses (Section 6.2) to protect the network topology.

Anomaly Detection: By monitoring data flows across DIFs, RINA can facilitate the detection of anomalies that might indicate attacks on the cognitive processes. For example, sudden deviations in decision patterns across multiple vehicles could trigger security alerts.

In this case study, RINA can ensure that the autonomous vehicles can make secure, reliable decisions even in the face of potential security threats, thereby maintaining the integrity of the entire transportation system.

8.5. Enabling Secure Edge Computing in Smart Manufacturing

Edge computing in IoT environments brings computation and data storage closer to the devices where needed, improving response times and saving bandwidth. However, it also introduces new security challenges. Let us consider a smart manufacturing scenario to illustrate how RINA could enable secure edge computing.

Scenario Overview: A large automotive manufacturing plant employs thousands of IoT sensors and actuators to monitor and control its production lines. The plant wants to implement edge computing to reduce latency for real-time process control, minimize data sent to the cloud for cost and privacy reasons, implement predictive maintenance using ML models at the edge, and ensure security of sensitive manufacturing data and processes.

Here is how RINA Addresses Secure Edge Computing Challenges:

1.

Secure Edge Nodes: RINA’s authentication mechanism (Section 6.12) ensures that only authorized edge devices can join the network. Each edge node would be part of a secure DIF, with its own authentication and access control policies.

2.

Data Isolation: RINA’s multi-layer approach (Section 6.10) allows for the creation of separate DIFs for different types of data or processes. For example:

• A DIF for real-time control data;
• A DIF for less time-sensitive monitoring data;
• A DIF for edge-to-cloud communication.

This segregation enhances security by limiting the potential impact of a breach.

3.

Secure Data Processing: RINA’s secure DIFs (Section 6.1) provide a protected environment for edge computation. Machine learning models for predictive maintenance can operate within a dedicated DIF, ensuring the integrity of both the model and the data it processes.

4.

Flexible Security Policies: RINA’s programmable DIFs (Section 6.14) allow for the implementation of context-aware security policies. For instance, stricter policies could be applied to DIFs handling sensitive production data.

5.

Efficient Resource Utilization: RINA’s Quality of Service mechanisms (Section 6.17) can be used to optimally allocate edge computing resources, ensuring critical processes receive priority.

6.

Scalability: As the number of edge devices grows, RINA’s recursive structure allows for seamless scaling. New edge nodes can be easily integrated into existing DIFs or new DIFs can be created as needed.

7.

Secure Edge-to-Cloud Communication: For data that need to be sent to the cloud, RINA’s layered security approach ensures end-to-end protection. The edge-to-cloud DIF can implement additional security measures such as encryption and access controls.

Implementation Example: In this smart manufacturing scenario, RINA could be implemented as follows:

• Sensor-level DIF: Manages communication between individual sensors/actuators and their local edge nodes. This DIF would be optimized for low-latency, secure data collection.
• Edge Compute DIF: Coordinates computation tasks across edge nodes. This DIF would implement load balancing and resource allocation policies to ensure efficient use of edge resources.
• Process Control DIF: Handles real-time control data for manufacturing processes. This DIF would have strict QoS policies to ensure timely delivery of critical control signals.
• Predictive Maintenance DIF: Manages the ML models and data for predictive maintenance. This DIF would implement specific security policies to protect the integrity of the ML models and the data they process.
• Edge-to-Cloud DIF: Handles communication between the edge network and cloud services. This DIF would implement additional security measures for data leaving the local network.

RINA’s hidden addresses feature (Section 6.2) would make it difficult for attackers to map the network topology, while the variable address space (Section 6.7) would allow for efficient addressing schemes tailored to the manufacturing environment.

RINA’s architecture can provide a comprehensive solution for secure edge computing in a smart manufacturing environment. Its ability to create secure, isolated communication environments, coupled with its flexibility and scalability, makes it well suited for the complex security requirements of edge computing in IoT. While implementation would require careful planning and optimization, RINA can offer a promising framework for realizing the full potential of secure edge computing in industrial IoT applications.

Table 3. Summary of RINA’s effectiveness across IoT use cases.

Use Case	Key Challenges	RINA Features Applied	Expected Benefits
Smart Home (Section 8.1)	Device heterogeneity, legacy integration, access control	AU, AC, CD, ML, PD	Unified security policy, simplified device enrollment, isolated guest access
Healthcare Monitoring (Section 8.2)	Legacy device support, data sensitivity, regulatory compliance	AU, CD, DF, ML, CC	Secure legacy integration via IoT sub-manager, end-to-end encryption, audit trails
Secure Multicast (Section 8.3)	Scalable key distribution, group management	RS, CD, ML	Native multicast support, per-DIF group policies, reduced bandwidth overhead
Autonomous Vehicles (Section 8.4)	Real-time constraints, V2X communication, adaptive security	PD, QS, MO, CD	Context-aware security policies, seamless handover, QoS guarantees
Edge Computing/Smart Manufacturing (Section 8.5)	Data isolation, edge-cloud security, ML model protection	ML, CD, PD, QS, AU	Isolated DIFs per data type, secure edge processing, scalable deployment

consolidates the key challenges, applied RINA features, and expected benefits across all five use cases, providing a compact reference for practitioners evaluating RINA’s applicability to specific IoT domains.

From Qualitative to Quantitative Validation. The preceding use cases demonstrate RINA’s architectural suitability for diverse IoT scenarios through qualitative analysis. However, a critical question remains: does RINA’s recursive structure provide measurable security benefits, or are the advantages purely conceptual? Specifically, we seek to validate whether the symmetry properties identified in Section 5.4—structural self-similarity across layers and controlled policy-driven asymmetry—translate into quantifiable improvements in threat detection. The following section addresses this question through a controlled experimental study.

9. Empirical Validation of the Symmetry Scoping Principle

The preceding sections established RINA’s symmetry properties theoretically: structural self-similarity across layers (Section 5.4), mechanism invariance with policy variance, and the formalized Symmetry Scoping principle (Section 5.4.4). A natural question arises: do these architectural symmetry properties translate into measurable security improvements, or are the advantages purely conceptual?

This section addresses this question by reinterpreting experimental results from our previous work on Learning-in-the-Middle (LIM) anomaly detection [12] through the symmetry framework developed in this paper. We demonstrate that the performance differences observed between scoped and global detection approaches are direct consequences of RINA’s symmetry properties, providing empirical validation for the theoretical framework presented earlier.

9.1. The Recursive Security Hypothesis

Our experimental investigation tests a specific hypothesis that emerges directly from the Symmetry Scoping Principle:

This hypothesis instantiates the Symmetry Scoping principle’s core claim: that symmetric mechanisms deployed with scope-aligned boundaries achieve better security outcomes than architecturally-agnostic approaches. The Learning-in-the-Middle framework provides an ideal test case because it directly operationalizes RINA’s recursive structure by placing anomaly detectors at each DIF layer, with each detector’s learning scope matching exactly one DIF’s communication scope.

9.2. Experimental Framework Overview

The complete experimental methodology, including simulation environment specifications, machine learning model configurations, traffic generation procedures, and detailed numerical results, is presented in [12]. Here, we summarize the key design elements relevant to validating the symmetry hypothesis.

9.2.1. Symmetry-Aligned Detection Architecture

The experimental framework compares two fundamentally different detection architectures:

LIM (Symmetry-Exploiting) Placement: One anomaly detector is instantiated inside every DIF traversed by network traffic—Sensor-DIFs, Edge-DIFs, and Central-DIF. Each detector observes only the traffic within its DIF scope. This placement directly exploits RINA’s structural self-similarity: identical detection mechanisms operate at every layer, but each instance’s observable scope matches exactly one DIF’s communication boundary.

Global (Symmetry-Ignoring) Placement: A single detector operates at the Central-DIF, observing aggregated traffic from all layers. This placement ignores the recursive structure, treating the network as a monolithic system rather than a hierarchy of symmetric components.

This comparison isolates the security contribution of respecting RINA’s recursive boundaries. Both placements use identical machine learning algorithms (Isolation Forest, One-Class SVM, and Auto-Encoder); the only difference is whether detection scope aligns with DIF scope.

9.2.2. Attack Scenarios

Three attack scenarios test different aspects of the symmetry hypothesis [12]:

• S1—Edge DoS: A spatially confined attack where one sensor floods its Edge-DIF uplink. The malicious signal is tightly scoped to a single DIF.
• S2—Tunnel Hijack: A cross-layer attack where an on-path relay manipulates traffic across multiple DIFs. The malicious signal spans the entire recursive hierarchy.
• S3—Cross-Layer Flood: A distributed attack where multiple sensors each generate small traffic increases that aggregate into significant volume at higher layers.

These scenarios span the spectrum from purely local (S1) to inherently global (S2) threats, enabling us to identify where symmetry-aligned detection provides advantages and where it faces limitations.

9.3. Interpreting Results Through the Symmetry Lens

The experimental results reported in [12] reveal consistent patterns that align precisely with predictions derived from RINA’s symmetry properties. We interpret these findings through three symmetry-based mechanisms.

9.3.1. Mechanism 1: Context Reduction Through Scope Alignment

The Symmetry Scoping principle predicts that scope-aligned detection should excel when threats are spatially confined, because limiting each detector’s view to a single DIF eliminates confounding patterns from other layers.

The experimental data confirm this prediction. In the Edge DoS scenario (S1), where the attack signal is confined to one DIF, scope-aligned detection achieved F1 scores approximately 10 percentage points higher than global detection at equivalent false-positive rates. This substantial improvement occurs because:

• The local detector observes only traffic patterns within its DIF scope;
• Legitimate traffic from other DIFs cannot dilute or mask the attack signature;
• The decision boundary need only distinguish normal from abnormal patterns within that scope.

This finding validates the “scope alignment” component of the Symmetry Scoping principle: when detection scope matches communication scope, the signal-to-noise ratio for threat identification improves.

9.3.2. Mechanism 2: Symmetry Enables Verification Reuse

A key operational implication of RINA’s structural self-similarity (Section 5.4.4) is that security properties verified for one DIF hold structurally for all DIFs. The experiments validate this at the detection level: identical Auto-Encoder architectures achieved consistent performance across Sensor-, Edge-, and Central-DIFs without requiring layer-specific tuning.

This uniformity contrasts sharply with heterogeneous architectures where different layers would require different detection approaches—network-layer monitors for IP anomalies, transport-layer monitors for TCP anomalies, application-layer monitors for protocol-specific anomalies. RINA’s symmetry eliminates this complexity: one detection mechanism, replicated across symmetric layers.

9.3.3. Mechanism 3: Controlled Symmetry-Breaking Reveals Limitations

The Symmetry Scoping principle acknowledges that scope-aligned detection has limitations: when threats genuinely span multiple layers, cross-layer context becomes valuable. The Tunnel Hijack scenario (S2) confirms this prediction.

When malicious activity permeates the entire recursive hierarchy, global detection approaches that aggregate cross-layer information showed competitive performance. The experimental data indicate that expressive density-based models (One-Class SVM) operating globally achieved comparable or slightly better F1 scores than local detectors in this scenario.

This finding does not contradict the symmetry framework—it validates the principle’s nuanced prediction that scope alignment is advantageous for scope-confined threats but may sacrifice useful information for truly cross-layer attacks. The practical implication is a hybrid defense strategy: deploy lightweight scope-aligned detectors for rapid local response, complemented by a global sentinel for threats that span the recursive hierarchy.

9.4. Quantifying Symmetry’s Security Contribution

The experimental results allow us to quantify the security benefit attributable to RINA’s symmetry properties:

Detection Improvement: For spatially confined attacks (the most common threat model in IoT), scope-aligned detection reduced missed detections by approximately 50% compared to global approaches. In operational terms, this translates to intercepting threats seconds earlier, potentially critical in real-time control systems.

Actionable Alerts: Because each LIM detector operates within a specific DIF, alerts include precise scope information (e.g., “anomaly detected in EdgeDIF#3”). This enables targeted response, isolating or rate-limiting only the affected slice rather than disrupting the entire network. Such precision is impossible with global detection, which can identify that an anomaly exists but not where in the recursive hierarchy it originates.

Resource Efficiency: The aggregate computational cost of multiple scope-aligned detectors approximately equals that of a single global detector, because each local instance processes a fraction of total traffic. RINA’s symmetry thus enables defense-in-depth without proportional resource overhead.

9.5. Validation of the Symmetry Scoping Principle

The experimental evidence supports each component of the Symmetry Scoping principle:

• Symmetry Test: Identical detection mechanisms (same algorithms, same architectures) operated successfully at every DIF layer, confirming that RINA’s structural self-similarity enables mechanism reuse across the recursive hierarchy.
• Scoping Test: Detection performance improved when each mechanism’s observable scope matched exactly one DIF’s communication scope, confirming that scope alignment provides measurable security benefits.
• Composition Test: The combination of multiple scope-aligned detectors provided defense-in-depth without the integration complexity that would arise from heterogeneous detection approaches, confirming that symmetric mechanisms compose cleanly.

These findings provide empirical grounding for the theoretical framework developed in this paper. RINA’s symmetry properties are not merely architectural elegance; they translate into quantifiable security improvements when properly exploited.

10. Discussion

10.1. Strategies for RINA Deployment in IoT Ecosystems

Our focus on RINA as a network stack solution, rather than concentrating on higher-layer security mechanisms, is driven by the potential for a clean-slate approach to address longstanding IoT security issues that have proven resistant to piecemeal solutions. However, the adoption of RINA in IoT environments represents a significant paradigm shift in network architecture, necessitating a carefully planned and phased deployment approach. This section explores various strategies and research efforts aimed at facilitating RINA’s integration into existing IoT infrastructures.

10.1.1. Leveraging RINA’s Compatibility Features

One of RINA’s key strengths lies in its ability to operate over shim DIFs, enabling functionality even on existing TCP/IP stacks. This compatibility feature is crucial for enabling a gradual transition from current network architectures to RINA-based systems. Research should focus on optimizing these shim DIFs to minimize performance overhead while maintaining RINA’s security benefits. Additionally, developing tools and methodologies for seamless migration from IP-based protocols to RINA-native implementations could significantly ease the adoption process.

10.1.2. Integration Strategies for Non-RINA Capable Devices

Study [81] presents a promising approach for implementing RINA in IoT environments where nodes lack direct RINA support. By introducing an IoT sub-manager that acts as an intermediary between non-RINA devices and the RINA network, this method allows for partial RINA deployment without requiring immediate changes to all endpoint devices. Future research could explore ways to enhance this sub-manager approach, potentially investigating how to minimize latency and optimize security in this hybrid setup.

10.1.3. Incremental RINA Adoption

Work [83] evaluates the feasibility of incrementally switching to RINA, focusing on scenarios where nodes can join a DIF directly via their first connected hop. This approach could be particularly valuable for organizations looking to pilot RINA in specific network segments before a full-scale deployment. Further research could explore optimal strategies for expanding these RINA-enabled network segments and managing the coexistence of RINA and non-RINA portions of the network during transition periods.

10.1.4. RINA on Resource-Constrained Devices

The RINAiSense project (See https://distrinet.cs.kuleuven.be/research/projects/RINAiSense, accessed on 2 January 2026) has made significant strides in investigating RINA’s viability on limited devices such as sensors. This work is crucial for IoT applications, where many endpoint devices have severe resource constraints. Future research in this area could focus on further optimizing RINA’s implementation for low-power devices, potentially exploring lightweight versions of RINA protocols that maintain core security features while minimizing computational and energy requirements.

10.1.5. Comprehensive Deployment Frameworks

Projects like OCARINA (See http://www.mn.uio.no/ifi/english/research/projects/ocarina, accessed on 2 January 2026) are taking a holistic approach to RINA deployment, addressing various aspects from performance optimization to security enhancements. These comprehensive efforts are essential for developing deployment frameworks that can be adapted to diverse IoT ecosystems. Research could continue to refine these frameworks, incorporating lessons learned from real-world pilot deployments and addressing challenges specific to different IoT application domains.

10.1.6. Bridging Legacy Applications

Work [84] on mapping the Transport Services (TAPS) API to RINA demonstrates a promising approach for enabling legacy applications to leverage RINA’s benefits. This strategy could be crucial for organizations with substantial investments in existing software ecosystems. Further research could explore similar bridging techniques for other common APIs and protocols, aiming to create a comprehensive suite of tools for integrating legacy systems with RINA-based networks.

10.1.7. Empirical Evidence of RINA’s Runtime Efficiency on Resource-Constrained IoT Hardware

Recent empirical work provides concrete evidence of RINA’s runtime efficiency on resource-constrained IoT hardware. Sarabia-Jácome et al. [60] deployed the RINAsense implementation on ESP32 microcontrollers in an operational smart building testbed, achieving an average round-trip latency of just 2.05 ms while reducing energy consumption by 82% compared to non-optimized operation, demonstrating that RINA’s architectural benefits do not come at the cost of runtime performance on constrained devices.

10.2. Applicability to Critical Infrastructure Domains

While this paper focuses on consumer and industrial IoT, RINA’s architectural principles extend naturally to mission-critical domains. In aviation and aerospace, RINA’s deterministic QoS (Section 6.17) and multi-path resilience (Section 6.19) align with the redundancy requirements of avionics networks, while mechanism-policy separation could facilitate safety certification. For space systems, RINA’s soft-state connections (Section 6.5) and delay-tolerant design suit the extreme latency and intermittent connectivity of satellite and deep-space communication. In large infrastructure systems (power grids, transportation networks), RINA’s hierarchical DIF structure maps naturally to geographic and organizational segmentation, with hidden addressing (Section 6.2) protecting against reconnaissance attacks. These domains represent promising directions for future research as legacy protocols face increasing security pressures.

10.3. Migration Roadmap

Transitioning from TCP/IP to RINA can follow a phased approach:

Phase 1—Overlay deployment: Deploy RINA over existing UDP/IP infrastructure using shim DIFs [60]. This enables operational experience without infrastructure changes. Entry points include isolated IoT segments (single buildings, production lines).

Phase 2—Gateway-mediated hybrid: Introduce RINA-native devices in new deployments while IoT sub-managers (Section 8) provide translation for legacy devices. The OCARINA and RINAsense projects have demonstrated this approach in practice.

Phase 3—Native greenfield deployment: New infrastructure projects adopt RINA natively, with gateway support for legacy interoperability.

Phase 4—Progressive replacement: As legacy devices reach end of life, they are replaced with RINA-native alternatives.

Several factors suggest RINA adoption is becoming viable: maturing open-source implementations (IRATI, rlite, RINAsense), SDN integration architectures [60], increasing IoT security incidents driving demand for architectural solutions, and edge computing trends favoring hierarchical, policy-driven models. The primary barriers are ecosystem development (vendor adoption, tooling) rather than technical limitations.

10.4. Further Research Directions

Our analysis reveals several concrete research gaps that merit investigation. We prioritize three directions that flow directly from limitations of the current study.

10.4.1. Empirical Validation on Resource-Constrained Hardware

While our qualitative analysis and RINASim-based experiments demonstrate RINA’s theoretical security advantages, a critical gap remains: quantifying RINA’s overhead on actual IoT hardware. Specifically, future work should address:

• RQ1: What is the memory footprint and CPU overhead of IPCP enrollment and authentication on Class 1 constrained devices (e.g., ∼10 KB RAM)?
• RQ2: How do RINA’s SDU protection mechanisms compare to DTLS in energy consumption per secured transaction?

The RINAiSense project has initiated work in this direction; extending these efforts with standardized benchmarks across device classes would provide the empirical foundation needed for practical IoT deployment.

10.4.2. Cross-Layer Threat Detection in Recursive Architectures

Our LIM experiments (Section 9) validated per-DIF anomaly detection, but the results also revealed a limitation: when threats span multiple layers (e.g., Tunnel Hijack scenario), global detection approaches showed competitive performance. This suggests a hybrid architecture merits investigation:

• RQ3: Can lightweight information sharing between adjacent DIF detectors improve cross-layer threat detection without sacrificing the locality benefits demonstrated in Section 9?
• RQ4: What fusion mechanisms optimally balance detection latency against accuracy for RINA’s recursive structure?

Preliminary directions include Kalman-based alert fusion and hierarchical federated learning across DIF boundaries.

10.4.3. Incremental Deployment and Legacy Interoperability

Section 8 introduced the IoT sub-manager concept for integrating non-RINA devices, but this approach requires further formalization:

• RQ5: What security guarantees can be preserved when RINA networks interface with legacy IP-based IoT segments via shim DIFs?
• RQ6: What is the minimum “RINA-enabled” fraction of an IoT deployment needed to achieve measurable security improvements?

Addressing these questions is essential for realistic adoption paths, as greenfield RINA deployments are unlikely in established IoT ecosystems.

Beyond these priorities, longer-term research could explore RINA’s intersection with emerging paradigms such as AI-driven adaptive security policies, Blockchain-based DIF governance for multi-stakeholder IoT federations, and energy-aware security mechanisms for sustainable IoT. However, we consider the three directions above as necessary foundational work before these extensions become tractable.

11. Conclusions

In this paper, we employed a mixed-methods research approach to evaluate the Recursive InterNetwork Architecture (RINA) as a transformative solution for IoT security. By combining a comprehensive qualitative analysis of RINA’s foundational principles with quantitative experimental validation, we provided a holistic assessment of its potential.

Our analysis revealed that RINA’s recursive design principles offer inherent security features capable of addressing many vulnerabilities present in current IoT network stacks. By integrating security at every layer of the communication stack and employing mechanisms such as secure Distributed IPC Facilities (DIFs) and hidden addressing schemes, RINA can provide robust defenses against a wide array of network attacks while maintaining high performance.

To illustrate RINA’s practical applicability, we explored several use cases across different IoT domains. In the smart home scenario, we demonstrated how RINA simplifies integration and enhances security in a RINA-native environment. The healthcare monitoring system showcased RINA’s ability to seamlessly integrate with legacy devices, ensuring secure and efficient data transmission. We addressed the challenge of secure multicast communications, a long-standing requirement in IoT networks, by highlighting RINA’s inherent support for such features. Additionally, we examined cognitive security in autonomous vehicle networks, illustrating RINA’s adaptability to complex, decision-making systems. Finally, we investigated secure edge computing in smart manufacturing, demonstrating RINA’s potential in industrial IoT applications.

These case studies underscore RINA’s versatility and its capacity to address real-world security and performance challenges in various IoT environments. They affirm that RINA’s architectural principles are not only theoretically sound but also practically applicable, offering tangible benefits in enhancing IoT network security and efficiency.

Looking forward, we identified promising avenues for future research, particularly in exploring RINA’s resilience to emerging threats such as adversarial machine learning attacks. RINA’s layered architecture and programmable DIFs provide a flexible framework that could potentially mitigate these sophisticated threats. However, further investigation is necessary to develop RINA-specific defenses and fully realize its capabilities in this context.

Central to RINA’s security advantages is the Symmetry Scoping principle: by maintaining structurally symmetric mechanisms across asymmetrically scoped layers, RINA achieves the verification reuse, composable guarantees, and scope-aligned observability that remain impossible in architecturally heterogeneous stacks.

Our mixed-methods analysis provides both a strong theoretical foundation and empirical evidence for considering RINA as a comprehensive solution to IoT network challenges. By rethinking fundamental networking principles and leveraging recursion, RINA offers a scalable, secure, and efficient architecture that has the potential to redefine the future of IoT networking. As pioneers in proposing RINA for IoT security, our work serves as a conceptual foundation, outlining the potential benefits and challenges associated with this approach. This groundwork is crucial for guiding future research, development, and implementation efforts in this promising direction.