ROS 2 on the open water.

DDS discovery is a network service. We treat it like one, and reach the motion planner from across the LAN.

ROS 2 replaced a custom transport with DDS, which is a real, standardised, industrial middleware. It is also a discovery protocol that multicasts on your network and, by default, trusts everyone who answers.

Discovery is the attack surface

Simple Discovery Protocol announces every participant, topic, and type on the local segment. An attacker on that segment does not need to break anything to learn the complete internal architecture of the robot — the robot tells them.

• Enumerate participants and topics passively in under a second.
• Join as a participant and subscribe to sensor topics.
• Publish to command topics that no subscriber authenticates.
• Starve a topic by publishing at a higher rate than the legitimate publisher.

SROS 2 exists

DDS-Security and SROS 2 give you authentication, access control, and encryption. Enabling them requires a certificate authority, per-node keys, and a policy file describing which node may publish what. That is real work, and it is why most deployments we see run without it.

A pragmatic path

• Segment first. If the robot network is reachable from the corporate LAN, fix that before anything else.
• Disable multicast discovery and use a discovery server with an explicit peer list.
• Turn on SROS 2 for command topics before sensor topics — integrity matters more than confidentiality here.
• Write the policy file as part of the system design, not as a retrofit.