Authentication-Transparent Protocol Extensions in Middleware-Relayed Systems

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

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

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 (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.¶

3. The Relay-Transparency Vulnerability Class

4. Protocol-Specific Demonstrations

  start = stream.find(0xFD)
  LEN   = stream[start + 1]
  frame = stream[start : start + 10 + LEN + 2]
  if crc_valid(frame):
      forward(frame)

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:¶

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

  /cmd_vel      geometry_msgs/Twist     (command payload)
  /cmd_vel/auth cleitonq_msgs/Auth      (ML-DSA-87 sig + nonce)

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

Author's Address