Individual Submission C. Bezerra Internet-Draft Independent Researcher Intended status: Informational 23 June 2026 Expires: 25 December 2026 Authentication-Transparent Protocol Extensions in Middleware-Relayed Systems draft-bezerra-relay-auth-transparency-00 Abstract Protocol-aware middleware (relays, bridges, gateways) re-serializes messages at their protocol frame boundary, silently discarding any bytes appended outside that boundary. Authentication material placed after the frame boundary by a sender is therefore stripped at every relay hop before reaching the receiver, with no error indication. This document identifies this behavior as a protocol design vulnerability class -- "relay-transparent authentication stripping" -- demonstrates it in three independent protocol stacks (MAVLink v2, ROS2/DDS CDR, and CAN/AUTOSAR SecOC), and specifies the architectural principle that authentication material must be carried as a first- class, independently addressable protocol unit to survive relay transit. Post-quantum cryptographic schemes (ML-DSA-87, ML-KEM-1024) are particularly susceptible due to their large signature and ciphertext sizes. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Bezerra Expires 25 December 2026 [Page 1] Internet-Draft Relay Auth Transparency June 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Relay-Transparency Vulnerability Class . . . . . . . . . 4 3.1. Structural Preconditions . . . . . . . . . . . . . . . . 4 3.2. Attack Model . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol-Specific Demonstrations . . . . . . . . . . . . . . 5 4.1. MAVLink v2 . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. ROS2 / DDS CDR . . . . . . . . . . . . . . . . . . . . . 6 4.3. CAN / AUTOSAR SecOC . . . . . . . . . . . . . . . . . . . 7 5. Impact and Severity . . . . . . . . . . . . . . . . . . . . . 7 6. Design Principle: Authentication-Transparent Extensions . . . 8 6.1. The CLEITONQ_CHUNK Pattern (MAVLink) . . . . . . . . . . 8 6.2. The DDS Parallel-Topic Pattern (ROS2) . . . . . . . . . . 9 6.3. General Principle . . . . . . . . . . . . . . . . . . . . 9 7. Guidance for Protocol Designers . . . . . . . . . . . . . . . 9 8. Guidance for Application Developers . . . . . . . . . . . . . 10 9. Post-Quantum Considerations . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. 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. Bezerra Expires 25 December 2026 [Page 2] Internet-Draft Relay Auth Transparency June 2026 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 (Section 3) * Demonstrates it in three independent protocol stacks (Section 4) * Provides the architectural principle that authentication material must be a first-class protocol unit to survive relay transit (Section 6) * Provides guidance for protocol designers and application developers (Section 7, Section 8) * Addresses post-quantum cryptography implications (Section 9) 2. 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 [RFC2119] [RFC8174] 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. Bezerra Expires 25 December 2026 [Page 3] Internet-Draft Relay Auth Transparency June 2026 3. The Relay-Transparency Vulnerability Class 3.1. Structural Preconditions All of the following conditions must be true for this vulnerability to apply: 1. 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). 2. At least one protocol-aware relay (bridge, gateway, router) exists on the path between sender and receiver. 3. 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. 3.2. Attack Model Precondition: An attacker controls, or is co-located with, a relay node on the sender-to-receiver path. Attack sequence: 1. Sender transmits an authenticated message: [frame | auth_bytes] 2. Relay parses [frame] at the frame boundary, discards [auth_bytes], and forwards [frame] only. 3. Attacker now has visibility of unauthenticated [frame] in transit. 4. Attacker can: a. 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 b. Substitute a different payload before the relay re- serializes, since no authentication exists in the forwarded frame. Bezerra Expires 25 December 2026 [Page 4] Internet-Draft Relay Auth Transparency June 2026 The receiver cannot distinguish case (a) or (b) from a legitimately authenticated message, because authentication was never carried in the forwarded frame. 4. Protocol-Specific Demonstrations 4.1. MAVLink v2 MAVLink v2 [MAVLINK] 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: start = stream.find(0xFD) LEN = stream[start + 1] frame = stream[start : start + 10 + LEN + 2] if crc_valid(frame): forward(frame) 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 | +--------------------------+------+----------+----------+ Table 1 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. Bezerra Expires 25 December 2026 [Page 5] Internet-Draft Relay Auth Transparency June 2026 * 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. 4.2. ROS2 / DDS CDR ROS2 uses Data Distribution Service (DDS) [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): Bezerra Expires 25 December 2026 [Page 6] Internet-Draft Relay Auth Transparency June 2026 +==========================+======+==========+==========+ | 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 | +--------------------------+------+----------+----------+ Table 2 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. 4.3. 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) [SECOCASR] 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 [R155]: the relay-transparency attack class should be assessed under the Tampering category for any gateway that handles safety-critical PDUs. 5. 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: Bezerra Expires 25 December 2026 [Page 7] Internet-Draft Relay Auth Transparency June 2026 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. 6. 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. 6.1. The CLEITONQ_CHUNK Pattern (MAVLink) CleitonQ [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. Bezerra Expires 25 December 2026 [Page 8] Internet-Draft Relay Auth Transparency June 2026 6.2. The DDS Parallel-Topic Pattern (ROS2) For ROS2/DDS deployments, authentication material MUST be published as a separate typed message on a parallel topic: /cmd_vel geometry_msgs/Twist (command payload) /cmd_vel/auth cleitonq_msgs/Auth (ML-DSA-87 sig + nonce) 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: 1. Subscribes to both topics. 2. Buffers /cmd_vel messages pending auth verification. 3. On receipt of /cmd_vel/auth, verifies the signature over the corresponding /cmd_vel payload. 4. Applies the command only after verification succeeds. 6.3. 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. 7. Guidance for Protocol Designers When designing an authentication extension for an existing embedded or cyber-physical protocol: 1. 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. Bezerra Expires 25 December 2026 [Page 9] Internet-Draft Relay Auth Transparency June 2026 2. 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. 3. 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. 4. 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). 8. Guidance for Application Developers When adding authentication to an existing embedded protocol deployment without the ability to change relay software: 1. 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. 2. If transport-layer security is unavailable: carry authentication as a separate, independently addressed protocol message (see Section 6). 3. Verify by measurement: route through all relay types present in the deployment and confirm auth bytes arrive at the receiver. 9. Post-Quantum Considerations Post-quantum signature schemes defined in FIPS 204 [FIPS204] (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 [FIPS203], 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. Bezerra Expires 25 December 2026 [Page 10] Internet-Draft Relay Auth Transparency June 2026 * 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 [CNSA20] 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. 10. Security Considerations This document describes a vulnerability class. The mitigations in Section 6, Section 7, and Section 8 address the class. Implementations following the parallel-message pattern (Section 6.2, Section 6.3) 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). 11. IANA Considerations This document has no IANA actions. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Bezerra Expires 25 December 2026 [Page 11] Internet-Draft Relay Auth Transparency June 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References [CLEITONQ] Bezerra, C., "CleitonQ: Relay-Transparent Post-Quantum Authentication for MAVLink v2 UAS Command and Control", DOI 10.5281/zenodo.20776349, GitHub cleitonaugusto/CleitonQ, 2026, . [CNSA20] NSA, "Commercial National Security Algorithm Suite 2.0", September 2022, . [DDS] Object Management Group, "Data Distribution Service (DDS) Specification, Version 1.4", April 2015, . [FIPS203] NIST, "FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)", August 2024, . [FIPS204] NIST, "FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)", August 2024, . [MAVLINK] Meier, L., "MAVLink Micro Air Vehicle Message Marshalling Library", 2009, . [R155] UNECE WP.29, "UN Regulation No. 155 on Cybersecurity and Cybersecurity Management Systems", 2021, . [SECOCASR] AUTOSAR, "Specification of Secure Onboard Communication (SecOC), Version 5.0.0", November 2021, . Author's Address Cleiton Augusto Correa Bezerra Independent Researcher Brazil Email: augusto.cleiton@gmail.com URI: https://github.com/cleitonaugusto/CleitonQ Bezerra Expires 25 December 2026 [Page 12]