PaperlayerView exact revision on arXiv

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

arXiv:2609.10024v1cs.RO

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.

    Source: §I · p. 1

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

    Source: §I · pp. 1–2

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

    Source: §I · p. 2, D. QKD mode: quantum key material… · p. 4, §XII · p. 6

  • Takeaways & Limitations

    AXON makes deployment-specific transport and explicit key establishment part of an alternative ROS 2 RMW design.

    Source: §I · p. 1, §XII · p. 6

    AXON is not DDS wire-compatible, lacks complete ROS 2 RMW conformance qualification, and depends on a forked TLS implementation requiring rebasing and review.

    Source: §XI · p. 6

Abstract

from arXiv · show

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.Source: §I · p. 1
  • AXON sacrifices DDS wire interoperability so controlled endpoint pairs can use transport tuned to their deployment.Source: §I · p. 1
  • 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.Source: §I · pp. 1–2
  • 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.Source: §I · pp. 1–2
  • 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.Source: §I · p. 2

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.Source: A. ROS 2, RMW, and DDS · p. 2
  • rmw_zenoh demonstrates that an RMW can retain the ROS 2 surface while replacing RTPS, a substitutability principle AXON follows.Source: A. ROS 2, RMW, and DDS · p. 2
  • QUIC supplies encrypted, multiplexed, connection-oriented UDP transport for cross-host traffic, while POSIX shared memory with eventfd and epoll avoids kernel copies locally.Source: B. Transports · p. 2
  • ETSI GS QKD 014 standardizes REST requests for KME-delivered symmetric keys, whose finite supply and request latency require an explicit consumption policy.Source: C. Quantum and post-quantum key… · p. 2
  • AXON’s classic configuration offers only X25519MLKEM768, whereas qkd uses domain-separated TLS 1.3 external PSKs containing the KME key_ID.Source: C. Quantum and post-quantum key… · p. 2

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.Source: §III · p. 2
  • The Rust core owns shared-memory rings, QUIC transport, discovery-daemon coordination, graph caching, wait sets, QoS interpretation, serialization, routing, and encryption.Source: §III · p. 2
  • 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.Source: §III · p. 2
  • 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.Source: §III · p. 3

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.Source: §IV · p. 3
  • Ring depth depends on QoS and message type, with burst-tolerant minimums and a bounded AXON_RING_BUFFER_SIZE_MB budget for large messages.Source: §IV · p. 3
  • 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.Source: §IV · p. 3
  • The auto-spawned daemon discovers peers using UDP multicast or broadcast fallback and maintains graph information for standard ROS 2 tooling.Source: §V · p. 3
  • Remote QUIC traffic uses multiplexed streams, compression above 1 KiB, ordered per-topic sending, and distinct reliable versus best-effort queue policies.Source: §VI · p. 3

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.Source: §VII · p. 3

Graph introspection

  • Graph introspection is treated as a correctness property because incorrect types or endpoint counts produce semantic errors for tools and users.Source: §VII · p. 3

Services and actions

  • Services use paired request/response topics with per-client response ownership, while actions build on services and topics.Source: §VII · p. 3

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.Source: §VIII · p. 3

Security modes

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.Source: B. Design goals • · p. 4

Fail-closed operation

  • If the configured security mode cannot be established, AXON prevents communication rather than silently downgrading.Source: B. Design goals • · p. 4

Key consumption

  • session consumes one KME key per daemon pair, while messages10 amortizes each data key across ten outgoing messages.Source: B. Design goals • · p. 4

Cryptographic scope

  • AXON contributes configuration and integration of standard cryptographic primitives rather than new cryptography.Source: B. Design goals • · p. 4

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

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.Source: D. QKD mode: quantum key material… · p. 4
  • 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.Source: D. QKD mode: quantum key material… · p. 4
  • The QKD handshake cannot fall back to X25519, ML-KEM, certificate-only exchange, or plaintext because those paths are not configured.Source: D. QKD mode: quantum key material… · p. 4

Application protection

Implementation

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.Source: D. QKD mode: quantum key material… · pp. 4–5

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.Source: E. Traffic protection · p. 5
  • AXON supports ChaCha20-Poly1305 or AES-256-GCM for negotiated QUIC traffic and makes no measured performance claim for either suite.Source: E. Traffic protection · p. 5
  • 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.Source: E. Traffic protection · p. 5

Configuration validation

  • Startup rejects unsupported modes or ciphers, incomplete QKD or SAE configuration, and obsolete variables that could otherwise create unintended settings.Source: F. Fail-closed enforcement · p. 5

Connection validation

  • Connection setup rejects security-mode mismatches, non-hybrid classic peers, unavailable QKD pair keys, unknown PSK identities, and incorrect binders.Source: F. Fail-closed enforcement · p. 5

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.Source: G. What this design does and does not… · p. 5
  • QKD mode authenticates possession of the KME-delivered pairwise PSK, whereas classic uses a single X25519MLKEM768 group without CA or fingerprint validation.Source: G. What this design does and does not… · p. 5, §IX · p. 5
  • AXON’s Rust core and C++ adapter are packaged as a selectable ROS 2 RMW, with runtime switching between classic and qkd modes.Source: §IX · pp. 5–6
  • QKD mode uses a forked rustls implementation to expose TLS 1.3 external-PSK and PSK-only handshake paths.Source: §IX · p. 5
  • Independent reproduction remains constrained because the linked repositories require GitHub authorization and need a public release or archival snapshot.Source: §IX · p. 6

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.Source: §X · p. 6
  • 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.Source: §X · p. 6
  • AXON is not DDS wire-compatible, and its reliability semantics have not been qualified as DDS-equivalent.Source: §XI · p. 6
  • QKD mode lacks independent Diffie-Hellman forward secrecy, so compromise of a session key exposes captured traffic from that session.Source: §XI · p. 6
  • The security modes must match across peers, and the application-key strategy is not advertised during discovery, making mismatches operationally significant.Source: §XI · p. 6
  • Handshake and steady-state overhead remain unquantified, and the redesigned security path lacks a controlled two-host campaign and third-party cryptographic audit.Source: §XI · p. 6

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.Source: §XII · p. 6
  • 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.Source: §XII · p. 6
  • The default QKD strategy rotates AES-256-GCM application keys after ten outgoing messages.Source: §XII · p. 6
  • Supporting TLS 1.3 external PSKs required extending rustls because the selected implementation did not expose that interface publicly.Source: §XII · p. 6
  • Future work includes full RMW conformance, overhead measurement, DDS and Zenoh comparisons, third-party rustls-fork review, and physical-QKD validation.Source: §XII · p. 6

Related papers

Loading 2609.10024v1…