As you may know, one of the Tier 1 RMW implementations for ROS 2 is based on RTI’s Connext. Prior to ROS 2 Galactic, the RMW implementation for Connext was called rmw_connext_cpp, and only supported Connext 5.3.1. From Galactic forwards, a brand-new RMW implementation called rmw_connextdds was developed by RTI, and supports both Connext 5.3.1 and Connext 6 when building from source.
While the new rmw_connextdds supports building against either Connext 5.3.1 or Connext 6, we can only choose one of those two options while building binary packages (debs or RPMs) on the ROS 2 buildfarm. In Galactic, we decided to stick with Connext 5.3.1 for backwards compatibility purposes.
For Rolling (soon to be Humble) on Ubuntu 22.04, we intend to build the binary distribution packages against Connext 6.0.1. The question for the community is whether this will significantly impact existing users. Please let us know in this thread if this will significantly impact your usage of ROS 2 from Humble forwards.
I’d just like to chime in and mention how useful having more than two DDS based RMW options has been for developing and debugging SROS2. There are often subtle discrepancies between the DDS Security standard provided by OMG and implementations developed by various vendors, thus having at least three supported vendors so far has made triaging such issues much more productive.
E.g. teasing out runtime configuration issues, introspecting access control failures from different angles with different logging sources, determining vendor interoperability and compliance deviations. I’m sure others here could recount many more similar merits for multi RMW support related to fine tuning QoS, profiling executor options, etc. As a real example, see the turtlebot3_demo maintained by the security working group: used in evaluating various DDS Security features and vendor implementations under realistic and common ROS2 use cases.
So, I’d really look forward to having binary installable support for Connext 6. Having used it myself (when building from source), I can attest Connext 6 is a notable improvement over Connext 5.3.1 when running Nav2 and SROS2. Not to mention the utilities and tools like the Administration Console are a lot more powerful. Although I think not all these additional tools and security plugins are included in it’s Open Community License, having out-of-the-box support for Connext 6 in ROS2 makes it a lot easer to utilize such features when paired with the professional or academic license. My one gripe would be that v6.0.1 doesn’t target the newer version of OpenSSL shipped with 22.04, thus adding to the installation complexity when relying on DDS Security features.
All and all, a real nice-to-have for SROS developers, IMHO.
@pakelihe this is not related to OpenSSL. The issue I was asking for is the ROS 2 reflection attack, which is feasible due to the way things are implemented in Connext. Alias Robotics posted about this recently, including a talk I gave at the Security WG explaining this in more detail and possibles attacks leveraging it. 6.0.1 is vulnerable.
I can confirm that the updated Debian packages contain the latest patched version of Connext (5.3.1.35 and 6.0.1.25). To be clear, the Debian packages contain the base RTI Connext DDS Professional libraries needed to build and run rmw_connextdds, but they do not include the DDS Security extensions.
I need to make a small correction regarding the “ROS 2 reflection attack”.
As mentioned in the linked article, the ROS 2 reflection attack is an issue that affects the OMG RTPS specification. An update to the DDS specification is being discussed in the OMG DDSI-RTPS 2.6 Revision Task Force whose output will be the RTPS protocol version 2.6.
RTI already provides mitigation to this problem by setting the authentication.participant_discovery_protection_key property, available with Connext DDS Professional version 6.1.0.
In previous versions, like 5.3.1.35 and 6.0.1.25, configuring accept_unknown_peers=false is a partial mitigation, as it will make the attack more difficult, but still possible. In this sense, the attacker will need to know at least one “known peer IP” and use it as part of the steps leading to the attack (important to note, the attacker will not need to own or be located in that IP).
Note that in addition to using Connext Secure, an alternative valid mitigation to this attack is to use either the TCP Transport with TLS Support or using the DTLS transport, which is strongly encouraged if using DDS in untrusted networks.
This is good to now, and as you say it’s not a full solution and may only slow down attackers in the best case. Endpoints using these versions would still be vulnerable to reflection attacks and their ROS 2 Nodes can easily get compromised. Attackers can spoof IP addresses by crafting custom packages easily and brute force such “known peer IPs” in search for responses until the right one’s found.
Actually, thinking about it, such brute forcing might actually be a information disclosure issue and a way to pivot into other DDS endpoints.
, which would be nice!).