Post-quantum authentication transparency in Isaac ROS relay topologies (MAVLink + ROS2 bridge)

Context

Isaac ROS deployments that relay MAVLink or ROS2 messages through middleware nodes
(ROS2 bridges, domain bridges, MAVLink routers) are affected by a protocol-level
vulnerability class: authentication-transparent relay stripping.

Any authentication material appended after a protocol frame boundary (MAVLink CRC,
CDR schema) is silently discarded at every relay hop. The receiving node has no
indication that authentication was ever present.

This was documented and confirmed in:

• GHSA-f5rj-mrxh-r7vm (GitHub Security Advisory, CVE pending)
• IETF Internet-Draft draft-bezerra-relay-auth-transparency-00
  https://datatracker.ietf.org/doc/draft-bezerra-relay-auth-transparency/
• Implementation: https://github.com/cleitonaugusto/CleitonQ

Specific impact on Isaac ROS

Isaac ROS navigation stacks typically include:

1. MAVLink ↔ ROS2 bridge (MAVROS or similar): MAVLink relay strips auth bytes
   before the bridge; the ROS2 side receives unauthenticated commands.

2. Multi-domain ROS2 (domain_bridge, zenoh-bridge): CDR deserialization reads
   exactly the IDL schema bytes; auth bytes appended after the schema are silently
   discarded at every bridge hop.

3. Jetson Orin + companion computer topologies: any relay between GCS and
   the Isaac ROS navigation stack is an authentication stripping point.

Post-quantum relevance

CNSA 2.0 (NSA) mandates ML-KEM + ML-DSA for National Security Systems after 2030.
Isaac ROS is already used in defense-adjacent robotics contexts where this timeline
is relevant. Post-quantum signatures (ML-DSA-87: 4627 bytes) cannot be appended to
frames — they must be carried as first-class typed messages.

Proposed fix pattern (tested, working)

Authentication material as a separate, typed ROS2 message on a parallel topic:

The subscriber verifies /cmd_vel/auth before acting on /cmd_vel.
DDS middleware forwards typed messages intact — their boundary is their own schema.

Reference implementation

CleitonQ implements this pattern for MAVLink (CLEITONQ_CHUNK) and documents
the ROS2 parallel-topic pattern:

• Repo: https://github.com/cleitonaugusto/CleitonQ
• IETF I-D: https://datatracker.ietf.org/doc/draft-bezerra-relay-auth-transparency/
• PoC: tools/ros2_bridge_strip_poc.py (simulate + real CycloneDDS)
• Security advisory: https://github.com/cleitonaugusto/CleitonQ/security/advisories/GHSA-f5rj-mrxh-r7vm

Question for the Isaac ROS team

Is there a planned security roadmap for Isaac ROS that includes:

1. PQC-ready authentication for the MAVLink ↔ ROS2 bridge?
2. Relay-transparent auth for multi-domain navigation stacks?
3. Integration guidance for CNSA 2.0 compliance in defense robotics use cases?

Happy to provide the PoC, benchmark data (ML-DSA-87 verify ~0.8ms on Neoverse-N2,
compatible with Cortex-A78AE on Orin), or collaborate on an Isaac ROS security layer.

Cleiton Augusto Correa Bezerra — Independent Security Researcher, Brazil
IETF I-D: draft-bezerra-relay-auth-transparency-00

No Isaac ROS files or tests are identified in the issue. Start by reviewing the referenced tools/ros2_bridge_strip_poc.py and the described MAVLink/ROS2 relay topologies, then locate the repository's relevant bridge or security entry points. A defined security roadmap and integration scope would be needed before completion can be measured.