Authentication-Transparent Protocol Extensions in Middleware-Relayed Systems

Introduction Embedded and cyber-physical systems increasingly rely on protocol-aware middleware components -- MAVLink relays, DDS bridges, CAN gateways -- to route messages between endpoints that do not share a direct link. These components are a fixture of drone command-and- control networks (MAVProxy, mavlink-router), robotic systems (domain_bridge, ros1_bridge), and automotive Ethernet architectures (DoIP gateways). A common pattern when adding authentication to existing embedded protocols is to append authentication material (HMAC tags, digital signatures, nonces) immediately after the protocol-defined frame boundary. This approach is attractive because it requires no changes to the protocol specification or to existing, unauthenticated endpoints. However, any protocol-aware relay along the path re-serializes messages at the protocol frame boundary. Bytes outside that boundary are in the relay's "discard" region. Authentication material placed there is silently stripped at every relay hop, with no error indication to sender or receiver. The receiver obtains a valid, unauthenticated frame. This document:

Defines the vulnerability class ()
Demonstrates it in three independent protocol stacks ()
Provides the architectural principle that authentication material must be a first-class protocol unit to survive relay transit ()
Provides guidance for protocol designers and application developers (, )
Addresses post-quantum cryptography implications ()

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Frame boundary:: The byte offset at which a protocol-aware parser considers the current message complete, as determined by the protocol's length-delimitation mechanism (e.g., a length field, a type schema, a DLC field).
Protocol-aware relay:: A software or hardware component that parses incoming messages at the protocol frame boundary, optionally processes or filters them, and re-serializes new conformant frames for forwarding. Distinct from a "transparent relay" that forwards raw bytes without parsing.
Relay-transparent:: An authentication encoding that survives transit through any protocol-aware relay on the path, emerging intact at the receiver.
Authentication stripping:: The silent removal of authentication material at a relay, caused by re-serialization at the frame boundary.

The Relay-Transparency Vulnerability Class

Structural Preconditions All of the following conditions must be true for this vulnerability to apply:

The protocol uses length-delimited framing (a length field, a type schema, or a hardware-defined payload size specifies the exact number of bytes in each message).
At least one protocol-aware relay (bridge, gateway, router) exists on the path between sender and receiver.
Authentication material is appended after the protocol-defined frame boundary, rather than carried in a separately addressed protocol unit.

When all three conditions are met, the relay MUST (per its correct implementation of the protocol) discard bytes outside the frame boundary during re-serialization. No error is generated. The receiver has no indication that authentication material was ever present.

Attack Model Precondition: An attacker controls, or is co-located with, a relay node on the sender-to-receiver path. Attack sequence:

Sender transmits an authenticated message: [frame | auth_bytes]
Relay parses [frame] at the frame boundary, discards [auth_bytes], and forwards [frame] only.
Attacker now has visibility of unauthenticated [frame] in transit.
Attacker can:
1. Forward the stripped frame (receiver accepts it as valid because it has no expectation of auth bytes being present when operating through a relay), or
2. Substitute a different payload before the relay re-serializes, since no authentication exists in the forwarded frame.

The receiver cannot distinguish case (a) or (b) from a legitimately authenticated message, because authentication was never carried in the forwarded frame.

Protocol-Specific Demonstrations

MAVLink v2 MAVLink v2 is the dominant command-and-control protocol for unmanned aerial systems. Each frame begins with a Start-of-Frame byte (0xFD) and a Length byte (LEN) at offset 1. The complete frame is exactly 10 + LEN + 2 bytes (10-byte header + LEN-byte payload + 2-byte CRC-16-MCRF4XX). Any protocol-aware relay (MAVProxy, mavlink-router, QGroundControl) implements the following parse-and-forward loop: Bytes at offset (start + 10 + LEN + 2) onwards are in the "discard" region. Three authentication schemes were tested against a MAVLink v2 COMMAND_LONG frame (45 bytes), all stripped:

Auth Scheme	Sent	Received	Stripped
HMAC-SHA3-256 (40 bytes)	85	45	40
Ed25519 (72 bytes)	117	45	72
ML-DSA-87 (4627 bytes)	4672	45	4627

MAVLink v2 defines a signing extension (INCOMPAT_FLAGS bit 0x01) that appends a 13-byte block (link_id + timestamp + truncated HMAC-SHA256). This extension survives relay transit on relays explicitly configured for signing support. However:

The signing block uses a 48-bit truncated HMAC-SHA256, providing only classical security.
A relay not configured for signing support treats INCOMPAT_FLAGS bit 0x01 as an unknown flag and MUST discard the frame per specification -- providing zero auth byte survival and frame loss.
A new INCOMPAT_FLAGS bit defined for post-quantum authentication would cause relay frame loss on all relays not updated to understand the new bit.

The INCOMPAT_FLAGS mechanism therefore cannot be used to introduce relay-transparent post-quantum authentication without a flag-by-flag negotiation across all relay software in the deployment.

ROS2 / DDS CDR ROS2 uses Data Distribution Service (DDS) for inter-process and inter-domain communication. Messages are serialized using CDR (Common Data Representation) according to the message type's IDL schema. The CDR frame boundary is defined by the IDL type schema: the deserializer reads exactly the number of bytes specified by the schema. Two failure modes were observed: CycloneDDS 11.0.1: The CDR deserializer reads exactly the schema-defined bytes. Bytes appended after the schema boundary arrive in the raw RTPS payload but are not transferred to any struct field. Re-serialization from the struct produces schema-sized bytes only. Authentication material is silently discarded. FastDDS (rmw_fastrtps_cpp, the default ROS2 RMW): Reader history buffers are pre-allocated to the type's maximum CDR length. Payloads exceeding this limit are rejected before reaching the application callback. Appending authentication bytes to a CDR payload causes the message to be silently dropped -- denial of service rather than silent stripping, but with identical impact on authentication visibility. Three authentication schemes were tested against geometry_msgs/msg/Twist (52-byte CDR payload):

Auth Scheme	Sent	Received	Stripped
HMAC-SHA3-256 (32 bytes)	84	52	32
Ed25519 (64 bytes)	116	52	64
ML-DSA-87 (4627 bytes)	4679	52	4627

Multi-domain deployments using domain_bridge, ros1_bridge, or zenoh-bridge-ros2dds compound this problem: each bridge deserializes and re-publishes a typed message, stripping any auth bytes at every hop.

CAN / AUTOSAR SecOC Controller Area Network (CAN) frames are hardware-delimited by the DLC (Data Length Code) field, which specifies 0-8 bytes (CAN 2.0B) or 0-64 bytes (CAN FD). Bytes outside the DLC-specified range cannot be represented in a CAN frame. AUTOSAR SecOC (Secure Onboard Communication) appends Freshness Values (FV) and MACs in PDU headers. CAN-to-Ethernet gateways (DoIP, SOME/IP) that are not SecOC-aware reassemble multi-frame ISO-TP sequences, extract the UDS application PDU, and re-serialize for the Ethernet domain. SecOC header fields outside the UDS PDU definition are not forwarded. The architectural root cause is identical to the MAVLink and DDS cases: re-serialization at the protocol frame boundary strips any out-of-band authentication. This is relevant to vehicle OEMs conducting TARA under UNECE WP.29 R155 : the relay-transparency attack class should be assessed under the Tampering category for any gateway that handles safety-critical PDUs.

Impact and Severity The relay-transparency vulnerability affects any deployment where:

Authentication is appended after the protocol frame boundary (rather than carried in a separate, first-class protocol unit), AND
At least one protocol-aware relay is on the sender-receiver path.

Impact:

Authentication Bypass:: The receiver accepts frames with no authentication material, having no way to distinguish them from legitimately authenticated frames (since both arrive stripped of auth bytes after relay transit).
Command Injection:: An attacker controlling a relay can substitute payloads after stripping, injecting arbitrary commands that the receiver treats as legitimate.
Denial of Service (FastDDS case):: Appending auth bytes causes the entire message to be dropped at the receiver, preventing legitimate communication.

The vulnerability is analogous to CWE-345 (Insufficient Verification of Data Authenticity), but the root cause is architectural rather than implementation-level: correct implementations of the protocol specification cause the stripping.

Design Principle: Authentication-Transparent Extensions Authentication material MUST be carried as a first-class, independently addressed protocol unit. The DDS middleware, MAVLink relay, or CAN gateway MUST forward this unit as an independent message -- whose byte boundary is defined by its own schema or frame header, not by its position relative to another message's boundary.

The CLEITONQ_CHUNK Pattern (MAVLink) CleitonQ implements relay-transparent post-quantum authentication for MAVLink v2 via the CLEITONQ_CHUNK encoding:

Authentication material (ML-KEM-1024 ciphertext, ML-DSA-87 signature, HMAC-SHA3-256 tag) is fragmented into 245-byte chunks.
Each chunk is encapsulated as a valid MAVLink v2 frame with its own MSG_ID (50000), LEN, and CRC.
INCOMPAT_FLAGS is set to 0. Any relay that does not know MSG_ID 50000 forwards it as a valid but opaque message. Any relay that knows the CleitonQ dialect forwards it with full understanding.
No relay has reason to discard the chunk: it is a well-formed MAVLink frame passing CRC validation.

This approach requires no relay software changes and no INCOMPAT_FLAGS negotiation. Authentication material arrives intact at any receiver connected through any standard MAVLink relay.

The DDS Parallel-Topic Pattern (ROS2) For ROS2/DDS deployments, authentication material MUST be published as a separate typed message on a parallel topic: The cleitonq_msgs/Auth type is defined in IDL. DDS middleware forwards it as any other typed message, with its byte boundary defined by its own schema. The receiving node:

Subscribes to both topics.
Buffers /cmd_vel messages pending auth verification.
On receipt of /cmd_vel/auth, verifies the signature over the corresponding /cmd_vel payload.
Applies the command only after verification succeeds.

General Principle For any protocol where the frame boundary is defined by a length field, a type schema, or a hardware-imposed maximum: Authentication material SHOULD be carried in a protocol unit with its own independent framing -- its own length field, schema, or CAN arbitration ID -- so that any protocol-aware relay can identify, forward, or route it independently of the message being authenticated. Authentication material SHOULD NOT be appended to an existing message frame beyond its protocol-defined boundary, regardless of whether the existing protocol version, receiver, or endpoint supports the authentication extension.

Guidance for Protocol Designers When designing an authentication extension for an existing embedded or cyber-physical protocol:

If the protocol has a first-class extension mechanism that is supported by all deployed relays (e.g., INCOMPAT_FLAGS bit 0x01 in MAVLink when all relay software is updated), use it.
If relay software cannot be universally updated, define the authentication material as a new message type with its own message ID (or topic, or PDU ID) within the protocol's normal addressing space.
Test authentication survival by routing through a conformant relay that does not have any special support for the authentication extension. Measure bytes received at the far end. They MUST equal bytes sent.
Document whether relays that do not understand the authentication extension will forward or drop the authentication message. "Forward as opaque" (unknown MSG_ID with INCOMPAT=0 in MAVLink) is preferable to "must discard" (unknown INCOMPAT_FLAGS bit).

Guidance for Application Developers When adding authentication to an existing embedded protocol deployment without the ability to change relay software:

If relay software cannot be changed: use a transport-layer security mechanism (DTLS, TLS, WireGuard) on the links between endpoints, bypassing the relay's protocol parsing entirely. Note that this requires the relay to forward raw UDP/TCP datagrams without parsing the payload.
If transport-layer security is unavailable: carry authentication as a separate, independently addressed protocol message (see ).
Verify by measurement: route through all relay types present in the deployment and confirm auth bytes arrive at the receiver.

Post-Quantum Considerations Post-quantum signature schemes defined in FIPS 204 (ML-DSA, formerly CRYSTALS-Dilithium) produce signatures of 2420 to 4595 bytes (ML-DSA-44 to ML-DSA-87), compared to 64 bytes for Ed25519. Post-quantum key encapsulation (FIPS 203 , ML-KEM-1024) produces a ciphertext of 1568 bytes. These sizes make the relay-transparency vulnerability significantly more consequential for PQC deployments than for classical ones:

Appending 64 bytes after a frame is plausible as a deployment workaround in some environments. Appending 4627 bytes is not.
Fragmentation of PQC material into multiple frames (as in the CLEITONQ_CHUNK pattern) is required for all current embedded protocols with payload size limits.
Any PQC authentication extension for an embedded protocol MUST be designed with relay transparency as a primary requirement, not an afterthought.

The CNSA 2.0 suite requires ML-KEM and ML-DSA for all National Security Systems after 2030. Defense and aerospace deployments transitioning to PQC should assume relay-aware authentication transport is mandatory, not optional.

Security Considerations This document describes a vulnerability class. The mitigations in , , and address the class. Implementations following the parallel-message pattern (, ) MUST ensure that:

The authentication message and the authenticated payload message are correlated by a sequence number, timestamp, or cryptographic binding, to prevent replay of authentication messages for previously authenticated payloads.
The receiver enforces a maximum time window between receipt of the payload and its corresponding authentication message, to limit the window for desynchronization attacks.
The authentication message itself cannot be used as a relay for oracle attacks (e.g., chosen-ciphertext attacks on the KEM ciphertext carried in an authentication message).

IANA Considerations This document has no IANA actions.