Source-linked AI summary
AXON: A ROS 2 RMW with Shared-Memory/QUIC Transport and QKD/ML-KEM Key Establishment
Sergio Sánchez de la Fuente, Miguel Ángel González-Santamarta, Francisco Javier Rodríguez-Lera, Vicente Matellán Olivera, Ángel Manuel Guerrero-Higueras
TL;DR
ROS 2’s DDS-based middleware does not tailor transport and key establishment to deployment scope or future cryptographic threats. AXON introduces a shared-memory/QUIC RMW with daemon coordination and two fail-closed TLS 1.3 configurations. The paper validates implementation boundaries and security behavior while explicitly limiting claims about ROS 2 conformance, performance, and physical QKD.
Problem
AXON addresses the limited transport specialization and future-cryptography coverage of uniform DDS-based ROS 2 middleware.
Method
AXON implements a Rust-core, C++-adapter RMW using shared memory locally, QUIC remotely, daemon coordination, and mutually exclusive ML-KEM or QKD external-PSK modes.
Results
AXON provides fail-closed remote key establishment: classic offers only hybrid ML-KEM, while qkd imports KME material as a TLS 1.3 external PSK and can rotate application keys every ten messages.
Takeaways & Limitations
AXON makes deployment-specific transport and explicit key establishment part of an alternative ROS 2 RMW design.
Takeaways & Limitations
AXON is not DDS wire-compatible, lacks complete ROS 2 RMW conformance qualification, and depends on a forked TLS implementation requiring rebasing and review.
Abstract
from arXiv · showhide
Robot Operating System 2 (ROS 2) standardizes application code against a middleware interface (RMW) whose reference implementations are built on the Data Distribution Service (DDS). We present AXON, an alternative ROS 2 RMW implementation that separates transport policy by deployment scope. A Rust core and C++ adapter use POSIX shared-memory rings for same-host communication, QUIC for remote communication, and a daemon for discovery and graph synchronization. We then describe two fail-closed TLS 1.3 key-establishment configurations for remote traffic. The classic configuration offers only the hybrid X25519MLKEM768 group, preventing negotiation of a classical-only group. The qkd configuration imports a 256-bit key obtained through the ETSI GS QKD 014 API as a pairwise external PSK and offers no Diffie-Hellman group. Its default messages10 strategy additionally protects remote application messages with AES-256-GCM, rotating KME material after ten outgoing messages and using a fresh nonce per envelope; session relies on QUIC protection alone. The external-PSK path requires a narrow extension to rustls, now bundled with AXON. We define the threat model, distinguish peer authentication in the two configurations, and delimit the implementation-level validation from ROS 2 conformance, comparative performance, and physical-QKD validation.
I. INTRODUCTION
AXON treats transport policy as deployment-specific rather than uniform, implementing a non-DDS ROS 2 RMW for systems whose endpoints intentionally select it. It combines shared memory, QUIC, daemon coordination, and fail-closed ML-KEM or QKD-based key establishment.
- ROS 2’s fixed RMW surface enables interchangeable middleware, but DDS treats local, LAN, WiFi, and NAT relationships as the same network problem.
- AXON sacrifices DDS wire interoperability so controlled endpoint pairs can use transport tuned to their deployment.
- Classic mode requires hybrid ML-KEM key exchange without a classical fallback, while qkd imports KME-delivered material into TLS 1.3 as an external PSK.
- AXON preserves the ROS 2 RMW API while routing same-host traffic over shared memory and cross-host traffic over QUIC, with daemon-based discovery and graph synchronization.
- The contributions include fail-closed negotiation, rustls support for TLS 1.3 external PSKs, and validation limited to ROS-facing behavior, transport paths, and security behavior.
II. BACKGROUND AND RELATED WORK
AXON builds on ROS 2’s substitutable RMW abstraction while replacing DDS/RTPS transport policy with shared memory locally and QUIC remotely. Its security background combines QKD-delivered symmetric material with post-quantum ML-KEM alternatives.
- ROS 2 messages use IDL and CDR, while the RMW contract covers publishers, subscriptions, services, graph introspection, wait sets, and QoS.
- rmw_zenoh demonstrates that an RMW can retain the ROS 2 surface while replacing RTPS, a substitutability principle AXON follows.
- QUIC supplies encrypted, multiplexed, connection-oriented UDP transport for cross-host traffic, while POSIX shared memory with eventfd and epoll avoids kernel copies locally.
- ETSI GS QKD 014 standardizes REST requests for KME-delivered symmetric keys, whose finite supply and request latency require an explicit consumption policy.
- AXON’s classic configuration offers only X25519MLKEM768, whereas qkd uses domain-separated TLS 1.3 external PSKs containing the KME key_ID.
III. SYSTEM ARCHITECTURE
AXON separates the ROS 2 adapter from a Rust-owned transport and coordination core through a stable C FFI. Its session and control/data-plane model isolates transport endpoints, graph state, discovery, and sample movement.
- AXON’s C++ adapter implements the RMW entry points and forwards transport decisions through a stable extern "C" FFI boundary.
- The Rust core owns shared-memory rings, QUIC transport, discovery-daemon coordination, graph caching, wait sets, QoS interpretation, serialization, routing, and encryption.
- Each rmw_init/rmw_shutdown pair forms an isolated session with separate transport endpoints and graph cache, while local rings are keyed by ROS_DOMAIN_ID.
- The control plane establishes peer and route state through discovery, graph synchronization, and security negotiation, while the data plane moves samples over shared memory or QUIC.
IV. LOCAL TRANSPORT: SHARED MEMORY
AXON uses bounded POSIX shared-memory rings for same-host samples and daemon-supported discovery, while remote samples use ordered QUIC pipelines with reliability-dependent backpressure.
- Same-host publishers write fixed-size shared-memory ring slots and signal subscribers through eventfd and epoll, with eventfds transferred using SCM_RIGHTS.
- Ring depth depends on QoS and message type, with burst-tolerant minimums and a bounded AXON_RING_BUFFER_SIZE_MB budget for large messages.
- Same-host shared memory is protected by filesystem permissions and treated as trusted for peers with sufficient OS privilege, while encryption applies only off-host.
- The auto-spawned daemon discovers peers using UDP multicast or broadcast fallback and maintains graph information for standard ROS 2 tooling.
- Remote QUIC traffic uses multiplexed streams, compression above 1 KiB, ordered per-topic sending, and distinct reliable versus best-effort queue policies.
VII. QOS, GRAPH, SERVICES, AND ACTIONS
AXON implements core ROS 2 communication features, including documented QoS checks, graph introspection, services, actions, and event multiplexing, while separating remote protection and authentication choices.
- QoS: AXON checks compatibility for reliability, durability, history, deadline, lifespan, and liveliness across publishers and subscriptions.
- Graph introspection: Graph introspection is treated as a correctness property because incorrect types or endpoint counts produce semantic errors for tools and users.
- Services and actions: Services use paired request/response topics with per-client response ownership, while actions build on services and topics.
- Security boundaries: Remote traffic always receives QUIC packet protection, while QKD messages10 additionally encrypt application payloads and shared-memory payloads remain unencrypted.The shared-memory boundary is the Unix account, /dev/shm permissions, and host integrity.
- Security modes: AXON offers two mutually exclusive fail-closed security modes, with peer authentication differing between QKD pairwise PSKs and the current classic certificate policy.
B. Design goals •
AXON’s design goals emphasize explicit protection layers, fail-closed configuration, bounded QKD key consumption, and integration of standard cryptographic primitives rather than new cryptography.
- Protection layers: QUIC/TLS always protects remote traffic, while messages10 optionally adds KME-keyed application-layer AEAD.
- Fail-closed operation: If the configured security mode cannot be established, AXON prevents communication rather than silently downgrading.
- Key consumption: session consumes one KME key per daemon pair, while messages10 amortizes each data key across ten outgoing messages.
- Cryptographic scope: AXON contributes configuration and integration of standard cryptographic primitives rather than new cryptography.
C. Classic mode: mandatory hybrid key exchange
AXON’s classic mode restricts TLS 1.3 to the hybrid X25519MLKEM768 exchange, while the QKD mode uses externally provisioned key material through an external-PSK path with no Diffie-Hellman group.
- Classic mode: Classic mode pins TLS 1.3 to exactly one hybrid group, X25519MLKEM768, combining ephemeral X25519 with ML-KEM-768.
- Classic mode: Because classic mode offers no classical-only group, peers unable to perform the hybrid exchange are rejected rather than accommodated.
- QKD mode: In QKD mode, the daemon retrieves a 256-bit KME key through ETSI GS QKD 014, while only its key identifier travels over discovery.
- QKD mode: AXON derives a TLS-specific 256-bit secret with HKDF-SHA256 and imports it as an external PSK with a namespaced KME key identity.The QKD provider offers psk_ke without supported groups or a key share, and the server verifies the TLS binder before selecting the PSK.
- QKD mode: The QKD handshake cannot fall back to X25519, ML-KEM, certificate-only exchange, or plaintext because those paths are not configured.
- Application protection: The messages10 strategy uses a 256-bit KME key for at most ten outgoing messages and a fresh 96-bit nonce for every AES-256-GCM encryption.
- Implementation: AXON bundles a narrow rustls fork to expose TLS 1.3 external PSKs, while retaining upstream rustls and quinn for record and packet protection.
- Security trade-offs: QKD mode lacks independent Diffie-Hellman forward secrecy, whereas classic mode retains ephemeral hybrid key establishment but currently lacks active-MITM prevention from certificate validation.
E. Traffic protection
AXON uses QUIC 1-RTT protection for remote traffic, validates security configuration before startup, and rejects incompatible peers or invalid key-establishment parameters.
- Traffic protection: Both AXON modes use ordinary QUIC 1-RTT packet protection, while QKD messages10 adds an independent AES-256-GCM application envelope.
- Traffic protection: AXON supports ChaCha20-Poly1305 or AES-256-GCM for negotiated QUIC traffic and makes no measured performance claim for either suite.
- Traffic protection: QUIC v1 Initial packets use mandatory AES-128-GCM keys derived from a published salt and connection ID, so they are not treated as confidential or integrity-protected.
- Configuration validation: Startup rejects unsupported modes or ciphers, incomplete QKD or SAE configuration, and obsolete variables that could otherwise create unintended settings.
- Connection validation: Connection setup rejects security-mode mismatches, non-hybrid classic peers, unavailable QKD pair keys, unknown PSK identities, and incorrect binders.
G. What this design does and does not claim
AXON provides implementation-level evidence for its transport and security mechanisms, while explicitly limiting claims about authentication, reproducibility, and broader security assurance.
- QUIC provides confidentiality, integrity, and replay protection after a valid handshake, but classic self-signed certificates do not establish peer identity.
- QKD mode authenticates possession of the KME-delivered pairwise PSK, whereas classic uses a single X25519MLKEM768 group without CA or fingerprint validation.
- AXON’s Rust core and C++ adapter are packaged as a selectable ROS 2 RMW, with runtime switching between classic and qkd modes.
- QKD mode uses a forked rustls implementation to expose TLS 1.3 external-PSK and PSK-only handshake paths.
- Independent reproduction remains constrained because the linked repositories require GitHub authorization and need a public release or archival snapshot.
X. VALIDATION SCOPE
Validation checks AXON’s transport, ROS-facing behavior, and security enforcement, but does not establish full conformance, comparative performance, cryptographic assurance, or physical-QKD validity.
- Implementation checks cover shared-memory and QUIC semantics, ROS publication and subscription, services, actions, graph synchronization, wait sets, and daemon restarts.
- These tests establish implementation-level consistency rather than a cryptographic proof, third-party audit, complete ROS 2 conformance qualification, performance benchmark, or physical-QKD validation.
- AXON is not DDS wire-compatible, and its reliability semantics have not been qualified as DDS-equivalent.
- QKD mode lacks independent Diffie-Hellman forward secrecy, so compromise of a session key exposes captured traffic from that session.
- The security modes must match across peers, and the application-key strategy is not advertised during discovery, making mismatches operationally significant.
- Handshake and steady-state overhead remain unquantified, and the redesigned security path lacks a controlled two-host campaign and third-party cryptographic audit.
XII. CONCLUSION
AXON demonstrates a deployment-scoped ROS 2 RMW that combines shared memory, QUIC, daemon coordination, and constrained key-establishment choices. Its external-PSK path required a narrow rustls extension, while broader comparative, audit, and physical-validation work remains open.
- AXON combines shared-memory host transport, QUIC cross-host transport, and a daemon-based control plane for ROS 2 communication.
- Remote key establishment is constrained to either hybrid X25519/ML-KEM without a classical-only group or KME-delivered material imported as an external PSK.
- The default QKD strategy rotates AES-256-GCM application keys after ten outgoing messages.
- Supporting TLS 1.3 external PSKs required extending rustls because the selected implementation did not expose that interface publicly.
- Future work includes full RMW conformance, overhead measurement, DDS and Zenoh comparisons, third-party rustls-fork review, and physical-QKD validation.