DDS-Security / SROS2

← Back to overview

The pain

DDS-Security (SROS2) is powerful but brittle to set up (22 reports). The recurring failure is that turning security on breaks discovery or communication, often with little diagnostic, plus genuine correctness gaps:

  • Enabling discovery encryption and topic-level protection together stops endpoints from matching.
  • Security with the Micro XRCE-DDS agent makes discovery fail outright.
  • Security enclave overrides don’t take effect — ros2 node list returns only system topics with security on.
  • Incomplete privilege inheritance has produced actual security vulnerabilities.

Most recent example

Fast-DDS#5753 — “Discovery Matching fails when discovery_protection_kind= ENCRYPT and topic-level protection are both enabled” (2025-04-08). Two standard, supported security settings combined cause endpoints to stop matching — security configuration as a discovery-breaker.

Reference list (most recent)

Date Source Problem
2025-04-08 Fast-DDS#5753 Discovery encryption + topic protection → no match
2025-03-13 Fast-DDS#5707 Security + Micro XRCE agent → discovery fails
2024-08-07 ros2#1589 Incomplete privilege inheritance → vulnerability
2024-05-08 sros2#306 Enclave override ineffective; only system topics visible
2024-04-17 sros2#293 Node list empty with security enabled

How ZeroDDS solves it

A complete DDS-Security 1.2 implementation, tested as a cross-vendor matrix — so “security on” is a tested configuration, not a cliff.

  • Full DDS-Security 1.2. Authentication, access control, cryptographic, logging and data-tagging built-in plugins are all implemented (including CRL and a conformance matrix). Security is not an afterthought layer that desyncs with discovery — it is part of the audited stack.
  • Secured discovery is a regression cell, not a surprise. The exact “encrypt discovery + protect topics” combinations that break elsewhere are cells in ZeroDDS’s cross-vendor security matrix, exercised against Cyclone, Fast DDS and OpenDDS. The secured handshake (authentication, key exchange, secured SEDP/data) is e2e-tested.
  • Profiles, not raw plumbing. A SecurityProfile plus a runtime_create_secure FFI entry point turns security on through a defined surface, rather than hand-assembling enclaves and governance/permissions XML whose mistakes fail silently.
  • Memory-safe by construction. The privilege/parse paths run in safe Rust with explicit bounds — the class of memory-safety vulnerabilities behind (ros2#1589) is not expressible in the safe core.

Honest status: secured cross-vendor interop is broad but not yet 100 % green in every cell (e.g. specific OpenDDS secured-SEDP decode paths are still being closed). Where a secured cell is verified we say so; the open cells are tracked, not hidden.

Why it no longer has to be a pain

The security cluster is security configuration that silently breaks discovery. ZeroDDS implements the full spec and treats the dangerous combinations as explicit regression tests across vendors, exposed through a profile API — so turning security on is a supported, tested step instead of a separate debugging project.

Reproduce it yourself

# Secured runtime via the profile + FFI entry point; cross-vendor secured matrix
# harness exercises encrypt-discovery + topic-protection combinations.

→ Back to overview · Next: Performance

DDS-Security / SROS2

← Zurück zur Übersicht

Der Schmerz

DDS-Security (SROS2) ist mächtig, aber fragil aufzusetzen (22 Reports). Der wiederkehrende Fehler ist, dass das Einschalten von Security Discovery oder Kommunikation bricht, oft mit wenig Diagnostik, plus echte Korrektheits-Lücken:

  • Discovery-Encryption und Topic-Level-Protection zusammen zu aktivieren hindert Endpoints am Matchen.
  • Security mit dem Micro-XRCE-DDS-Agent lässt Discovery komplett scheitern.
  • Security-Enclave-Overrides greifen nicht — ros2 node list gibt mit Security nur System-Topics zurück.
  • Unvollständige Privilege-Inheritance hat tatsächliche Sicherheitslücken produziert.

Jüngstes Beispiel

Fast-DDS#5753 — „Discovery Matching fails when discovery_protection_kind=ENCRYPT and topic-level protection are both enabled” (2025-04-08). Zwei standardmäßige, unterstützte Security-Einstellungen kombiniert lassen Endpoints aufhören zu matchen — Security-Konfiguration als Discovery-Brecher.

Referenzliste (jüngste zuerst)

Datum Quelle Problem
2025-04-08 Fast-DDS#5753 Discovery-Encryption + Topic-Protection → kein Match
2025-03-13 Fast-DDS#5707 Security + Micro-XRCE-Agent → Discovery scheitert
2024-08-07 ros2#1589 Unvollständige Privilege-Inheritance → Vulnerability
2024-05-08 sros2#306 Enclave-Override wirkungslos; nur System-Topics sichtbar
2024-04-17 sros2#293 Node-Liste leer mit aktivierter Security

Wie ZeroDDS es löst

Eine vollständige DDS-Security-1.2-Implementierung, getestet als Cross-Vendor-Matrix — sodass „Security an” eine getestete Konfiguration ist, keine Klippe.

  • Volle DDS-Security 1.2. Authentication-, Access-Control-, Cryptographic-, Logging- und Data-Tagging-Built-in-Plugins sind alle implementiert (inkl. CRL und einer Conformance-Matrix). Security ist keine nachträgliche Schicht, die mit Discovery desynct — sie ist Teil des auditierten Stacks.
  • Secured Discovery ist eine Regressions-Zelle, keine Überraschung. Genau die „encrypt discovery + protect topics”-Kombinationen, die anderswo brechen, sind Zellen in der Cross-Vendor-Security-Matrix von ZeroDDS, gegen Cyclone, Fast DDS und OpenDDS exerziert. Der Secured-Handshake (Authentication, Key-Exchange, Secured-SEDP/Data) ist e2e-getestet.
  • Profile, kein rohes Plumbing. Ein SecurityProfile plus ein runtime_create_secure-FFI-Entry-Point schaltet Security über eine definierte Oberfläche ein, statt Enclaves und Governance-/Permissions-XML von Hand zusammenzubauen, deren Fehler still scheitern.
  • Memory-safe by construction. Die Privilege-/Parse-Pfade laufen in sicherem Rust mit expliziten Bounds — die Klasse von Memory-Safety-Vulnerabilities hinter (ros2#1589) ist im sicheren Kern nicht ausdrückbar.

Ehrlicher Status: Secured-Cross-Vendor-Interop ist breit, aber noch nicht in jeder Zelle 100 % grün (z.B. werden spezifische OpenDDS-Secured-SEDP-Decode-Pfade noch geschlossen). Wo eine Secured-Zelle verifiziert ist, sagen wir es; die offenen Zellen werden getrackt, nicht versteckt.

Warum es kein Schmerz mehr sein muss

Der Security-Cluster ist Security-Konfiguration, die still Discovery bricht. ZeroDDS implementiert die volle Spec und behandelt die gefährlichen Kombinationen als explizite Regressions-Tests über Vendoren, exponiert über eine Profile-API — sodass das Einschalten von Security ein unterstützter, getesteter Schritt ist statt eines separaten Debugging-Projekts.

Selbst reproduzieren

# Secured-Runtime via Profile + FFI-Entry-Point; Cross-Vendor-Secured-Matrix-
# Harness exerziert encrypt-discovery + topic-protection-Kombinationen.

→ Zurück zur Übersicht · Weiter: Performance