Rolling/Humble update to RTI Connext 6

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.

Your friendly ROS 2 team


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.

I also agree getting Connext 6.0.1 for Rolling would be fantastic.

As a security concern, @clalancette would recent security research results be mitigated as part of the deb release (e.g. the ones disclosed at Cybersecurity in the ROS 2 communication middleware, targeting the top 6 DDS implementations)? RTI seems to indicate in ICS-CERT Security Notice ICS-VU-575352 / VU#770071 | Data Distribution Service (DDS) Community RTI Connext Users that this needs to be done manually.

RTI is supplying the packages, so I assume those have the latest security fixes. But pinging @asorbini_rti for confirmation.

While I’m not Andrea, I am an Application Engineer with RTI. Connext 6.0.1 and Connext 6.1.0 both support the latest OpenSSL

@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.

This issue was initially reported as CVE-2021-38487, and there’s plenty of information about it available publicly as of now. The only advisory available from RTI that I’m aware of is ICS-CERT Security Notice ICS-VU-575352 / VU#770071 | Data Distribution Service (DDS) Community RTI Connext Users, which doesn’t say much (not even crediting back the security researchers :wink: , which would be nice!).

Is a patch available for 6.0.1 and if so, will the version that will be provided to Open Robotics be patched?

I’ll ask our support manager. If a patch would be required, I’m sure that we’d be happy to provide one to Open Robotics.

They like to keep us Application Engineers from having to know all of the intricacies of vulnerabilities.

I’ll let you’ll know when I’ve got an answer.

I can confirm that the updated Debian packages contain the latest patched version of Connext ( and 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.

CVE-2021-38487 impacts the DDSI-RTPS specification (not the DDS-SECURITY one).

Will and be patched against CVE-2021-38487 and other discussed flaws at Cybersecurity in the ROS 2 communication middleware, targeting the top 6 DDS implementations @asorbini_rti?

My note was directed at @ruffsl who mentioned the use of Connext 6 with SROS2, which would require DDS Security support.

Both and include patches for the vulnerabilities affecting RTI Connext DDS that are mentioned in the linked article.

1 Like

And closing the loop here, Andrea had worked directly with support to get this information, in advance of me. I should have known he’d be ahead of me.

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 and, 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.

1 Like

Can you explain how that property works?

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.