A security use case !
Happy to try and help @tomoyafujita. Though I might be misunderstanding some aspects of your initial problem description, so feel free to clarify.
Here’s my understanding:
Your requirement is to maintain high-performance communication within the Awesome robot
by keeping local communication unsecured, while enabling secure communication (ROS 2 security by means of an implementation of the DDS Security plugins) only with specific external entities, e.g. End user's PC (authenticated)
. Then, you have another End user's PC /Device (unauthenticated)
which is not making use of such security mechanisms, that you want it interacting with Awesome robot
.
My take on this is that technically, what you’re trying to do implies enabling an attack vector into your Awesome robot
since you’d be requiring some sort of Insecure Node (Pub/Sub)
or alternative interface (does not necessarily need to be a complete ROS 2 Node, with all abstractions for interop.).
So, if I’m not mistaken, I believe that you’re hoping to achieve something as:
To do so, you could rely on third party components, as you suggest, but that assumes those components mitigate such security flaw, so your security would be reliant on them. My suggestion is to avoid that decision, as adding more complexity to your system difficults its security (security and complexity aren’t best friends), and your internal security assessment actions.
Instead, you can technically enable this by implementing your own bridging within Insecure Node (Pub/Sub)
via already used and assumed security-reliable technologies. E.g. inter- or intra-process communications and handling discovery via fixed identifiers (e.g. IP). Regardless of which technical avenue you use for interoperability, mitigating this security flaw is needed.
To do so, I’d suggest (again) you rely on technology that’s already present in your system and assumed/assessed/tested (something you should validate experimentally via a pentest or similar exercises) as secure. In particular, I’d go for something like network segregation, or specifically logical network segmentation. A great way to do so is using a VPN. Wireguard works great in my experience and plays along with ROS 2.
By doing so, despite not having security at the application layer, you’d be adding security at the network layer. It could be understood as something like:
I would also consider extending such VPN to the overall setup. Depends on your use case latency requirements, but definitely worth it in in many scenarios. Taken from some work last year we’re yet to publish:
(VPN implementation in this case corresponds with Wireguard)