Introduction:

In today's technological landscape, addressing security concerns and implementing robust policies in distributed applications is crucial. 

To address those concerns, RTI provides Connext DDS Secure. It provides robust authentication, encryption, and access control mechanisms for Data Distribution Service (DDS) systems. With fine-grained control of the publication and subscription of topic data, data encryption,  and data filtering, and integration with external security infrastructure, Connext DDS Secure restricts network access to authenticated and authorized participants, protecting the integrity and confidentiality of the data and data flows. It complies with security standards, offers performance optimization, and facilitates secure data caching and persistence.

Connext DDS Secure uses standard PKI-based techniques for mutual authentication. After authentication, the key material used to protect the information exchanged between two Participants is generated on the fly using standard Ephemeral Diffie-Hellman Key agreement algorithms.  This is aligned with modern best practices for distributed system security (including most of the web traffic today)  and provides important benefits such as the so-called “perfect forward secrecy”.

However, any system that relies solely on mutual authentication has an inherent weakness to denial of service attacks (DoS). In essence a system must be ready to engage on an authentication handshake with anyone that wants to communicate with it. This involves exchanging messages that require performing cryptographic operations that consume CPU and memory resources. An attacker can therefore cause an application to consume its resources by initiating an authentication handshake. The handshake will fail given the attacker does not have the necessary credentials, nevertheless it has caused the targeted application to consume its resources. Increasing the number and frequency of attacks can degrade the targeted application’s performance, and in the extreme render it unable to perform its intended function. One approach to limit DoS attacks is to “harden” the network by incorporating a layer of protection that relies on a “pre-shared-secret” so applications that do not possess those secrets are not even able to engage in authentication handshakes. Connext DDS Secure does offer this capability. However there are situations where the management and distribution of that secret is not practical.  For example, encryption libraries (SSL) are not available for a specific platform, or we do not want to use cryptography to address security concerns. RTI’s Research Group has been investigating potential approaches to hardening Connext DDS Secure deployments that do not require pre-shared secrets by leveraging the network-level policy-enforcing capabilities available in modern operating systems and routers. This approach is complementary to the use of encryption for secure data distribution – it focuses on network layer 2 enforcement of policies and network control within the context of the Data Distribution Service (DDS).

The primary benefit of this approach is to augment the security mechanisms provided by Connext DDS Secure. However, this technique might also be used in systems that elect not to use DDS security.  In this case the techniques described here can still provide some degree of access control and protection, albeit weaker and less granular then DDS Secure. Nonetheless it can still help retrofit deployed legacy systems that do not use DDS Security, or extend the use of DDS Security to extremely resource-constrained environments that do not have the capacity to run cryptographic functions.

This post aims to shed light on what we have been doing so far and, most importantly,  to foster discussion, gather ideas, and seek feedback on potential applications and avenues for further exploration.

It is important to note that the information presented here is based on ongoing research and proof-of-concept (PoC) developments. 

Before diving into the technical details, it's essential to establish some upfront disclosure and limitations:

1. This is research: The information presented here is not intended as a product description but rather an exploration of what is possible and as a means to develop new ideas.
2. Proof-of-Concept (PoC): The PoCs developed during this research phase are not comprehensive frameworks but rather demonstrations of the concept's viability.
3. Acknowledging Limitations: It's important to acknowledge the limitations of the PoCs, such as potential challenges when dealing with encrypted traffic, certain communication patterns, or limited capabilities when it comes to parsing the RTPS network packets.

A simple scenario: Enforcing Security Policy for Topic Filtering

To illustrate the approach, let's consider a simple scenario involving two RTI Shapes Demo applications running on two separate nodes. The first application publishes two topics: Square and Circle. The second application subscribes to both topics. The goal is to enforce a policy that allows only the "Square" topic to reach the subscriber node.

 

This behavior can be solved using RTI Connext Secure. The Policy would be expressed using the following XML:

<grant name="RTI Shapes Demo">    <allow_rule>     <domains>        <id>0</id>      </domains>      <subscribe>         <topics>            <topic>Square</topic>          </topics>      </subscribe>    </allow_rule>    <default>DENY</default>  </grant>

To achieve this without using encryption and Connext Secure, we have implemented  an OS kernel-level Policy Enforcement Point (PEP) that can be deployed on different systems. The PEP Engine conducts deep packet inspection and allows packets that adhere to the configured policies while blocking those that violate the user-defined rules.

Starting from the DDS Security Policy shown above, a set of rules can be generated. For example:

1. ALLOW --app "RTI Shapes Demo" --domain 0 --topic Square

2. DENY OTHERS

At the moment, these rules are manually translated from the original Connext Secure Policy, but in the future it could be done automatically with a tool.

These rules are fed into our PEP Engine, which enforces them. 

So, to recap we can look at the following figure:

 

The RTI Connext Secure Policies are our input (written manually or generated with a graphical tool [link to cameo research / plugin]. Then, a Translator will generate rules that are enforced by the PEP Engine. At the moment the Translator job is done manually but this could be automated. 

Policy Enforcement Point (PEP) Architectures

Before getting into the details on how the PEP Engine is implemented, we have to enumerate the possible configurations. We explored three possible answers:

1. On each single node → We called this ‘Distributed PEP’ 

2. On the local network router → We called this ‘Packet Routing PEP’

3. On dedicated hardware or a virtual network switch that can analyze all network traffic bridged through it → we called this ‘Packet Bridging PEP’

A brief explanation for each of these architectures follows:

Distributed Per-Node PEP

This architecture applies to most network topologies because the PEP Engine would be installed on each node, and the rules would then be distributed to each engine using tools like Ansible or Terraform.

 

 

Packet Routing PEP

This architecture enforces rules between LAN and WAN networks. The PEP is installed on the router, allowing centralized enforcement of rules for all packets going to and from the LAN. Various Linux-based routers supporting iptables, such as DD-WRT, Open-WRT, and others, can be used.

 

Packet Bridging PEP

This architecture enforces rules within a LAN without installing the PEP on each node. By utilizing a managed switch capable of implementing 802.11Q V-Lan tagging and a microkernel-equipped Raspberry Pi, the PEP Engine runs on a single point, ensuring policy enforcement.

 

 

Implementation of the PEPs

The prototypes that we  developed use iptables for both the Distributed PEP architecture  for the Packet Routing PEP.  For the Packet Bridging PEP architecture, we used a custom packet filter developed on top of the seL4 microkernel. 

PEP using netfilter/iptables

We used iptables because it is a powerful firewall utility commonly used in Linux operating systems to manage network traffic. It serves as a front-end tool for managing the netfilter firewall system that is built into the Linux kernel. With iptables, system administrators can define a set of rules and filters to control incoming and outgoing network packets, allowing or denying access based on various criteria such as source and destination IP addresses, ports, protocols, and connection states. By manipulating these rules, iptables provides a flexible and robust solution for network security, enabling administrators to secure their systems, create network address translation (NAT) setups, set up port forwarding, and perform other network-related tasks. It is a versatile and widely used tool that offers fine-grained control over network traffic, making it an essential component in ensuring the integrity and security of Linux-based networks.

iptables can be extended with custom modules providing the flexibility to enhance its functionality and tailor it to specific requirements. We created our own kernel module that is able to parse RTPS packets and match their content with parameters passed to the module by the operator. A kernel module is allowed to interact directly with the Netfilter framework and  to hook into different stages of packet processing and modify packet behavior. By writing custom modules, administrators can introduce new match criteria or target actions that are not available in the standard iptables package.A module is composed of a library to parse arguments in user space (lib_pep.so) and a library to process each packet and ‘match’ them with the parameters. We developed an RTPS-aware kernel module called rtpsParser.c.

 

 

Once loaded, our module can be used to express complex rule like the following:

1. iptables -A INPUT -m rtipep --other -j ACCEPT
2. iptables -A INPUT -m rtipep --app "RTI Shapes Demo" --topic Square --domain 0 -j ACCEPT
3. iptables -P INPUT DROP

The big advantage of using iptables is that it can be combined with all the other tools offered by a standard linux distribution. For example, we could use ipset, logging functionality, and so on to manage our RTPS traffic. 

PEP using seL4 and VLAN

In the bridged scenario, we are enforcing the policies directly at the packet switching layer. Unfortunately commercial hardware that have the capability to be programmable are quite expensive as they are designed to target data centers. As a PoC solution, we used a commercial, off the shelf managed switch that is capable of supporting VLAN tagging (802.11Q and PVID). 

With this more advanced configuration, we set up the managed switch rules to tag incoming traffic with a unique VLAN ID, shared only with a common port containing the machine that is manually performing the switching of the packets and running the PEP. We also use the special VLAN ID=255 to identify all the ports (to use as system-wide broadcast originating from the PEP) and 254 to identify all the ports except for the uplink (to use as local broadcast originating from the PEP)

 

In the above example:

• Port #1: VLAN ID=1, 255, PVID=1
• Port #2: VLAN_ID=2, 254, 255, PVID=2
• ...
• Port #23: VLAN_ID=23, 254, 255, PVID=23
• Port #24L VLAN_ID=1,2,3,4,5,6,7,8,9... 23, 254, 255. Tagged port (no PVID),

 With this configuration, the device connected on port #24 receives all the traffic from all the ports, with the Ethernet 802.11Q header extension containing the VLAN_ID. The software (that operates the switching at L2 of the TCP/IP stack):

• Analyzes the ethernet frame and builds a map of MAC addresses and ports
• Parses and analyzes the payload
• Enforce the security policy. If the packet is not allowed to continue, drop it.
• If the packet is allowed to continue, determine the destination port by looking at the target MAC address and the target port
• Then replace the VLAN Tag with the ID of the destination port and send it back to the switch
• The switch then delivers the packet to the corresponding port based on the VLAN tag in the packet.

In case of a broadcast packet, the PEP device uses:

• VLAN ID=255 to address all the ports: 1-23
• VLAN ID=254 to address all the ports except for the first one: 2-23 (the software need to exclude port #1 from broadcast packets originated from port #1 itself to avoid infinite loops between bridged LAN segments).

In the implementation of the PEP device we used a Raspberry PI 3B+ running TRENTOS-M ( based on seL4 microkernel + CAmkES component-based framework), and used the USPi bare metal USB + network driver for Raspberry PI.

A more complex scenario: hospital 

As another example, a hospital local area network is connected via a router to a cloud environment. 

 

 The PEP is installed on the router and enforces the following rules:

 1. iptables -A FORWARD -m rtipep --other -j ACCEPT

2. iptables -A FORWARD -m rtipep --app NurseStation --topic OxygenTopic -j ACCEPT 

3. iptables -A FORWARD -m rtipep --app NurseStation --topic TemperatureTopic -j ACCEPT

4. iptables -A FORWARD -m rtipep --app Billing --topic PatientTopic -j ACCEPT 

iptables -P INPUT DROP

Rule #1 allows all traffic that is not a UserData or Discovery Packet to go through (e.g. NDDSPING or ACK). Rule #2 allows an application named NurseStation to subscribe to the topic OxygenTopic. Rule #3 allows NurseStation to subscribe to TemperatureTopic. Finally, rule #4 allows the Billing application to receive PatientTopic. If the CompromisedNurseStation tries to subscribe to the Temperature topic, it will not work.

Conclusion and Next Steps

In this post, we have explored potential solutions for enforcing DDS policies outside of DDS Security – at the network level. The presented prototypes and architectures provide a foundation for further exploration, aiming to gather feedback, ideas, and suggestions from the readers. The possibilities for filtering and controlling DDS traffic extend beyond topics, including considerations like QoS, content filters, and data-based filtering.

Moving forward, discussion and collaboration are sought to determine the focus areas and potential product explorations that readers would find valuable. The research is still at an early stage, and contributions from the community can play a significant role in shaping the future direction of this project.

Please share your thoughts, ideas, and suggestions on how to advance this research and explore additional applications and use cases.

Note: The content presented in this post is based on ongoing research and proof-of-concept development and should not be considered as an endorsement or recommendation for a specific product or framework.