14. Control Frames

PALISADE defines control frames for in-band signaling of protocol-level events such as rekeying, migration, and session closure.

Control frames are encrypted and authenticated identically to application data and are carried within the normal packet payload.

14.1 Control Frame Identification

A packet contains a control frame if and only if:

PublicHeader.flags.bit0 (control_frame) is set to 1.

Packets with this bit unset MUST be treated as application data packets.

The control frame indicator is visible only in the cleartext PublicHeader; all control frame contents are encrypted.

14.2 Control Frame Format

After decryption, a control frame has the following structure:

ControlFrame =
    ctrl_type   (1 byte)
    length      (3 bytes, unsigned big-endian)
    ctrl_data   (length bytes)

Where:

• ctrl_type identifies the control operation.
• length specifies the exact length of ctrl_data.
• ctrl_data is interpreted according to ctrl_type.

All control frames MUST be fully contained within a single encrypted packet.

14.3 Control Frame Types

The following control frame types are defined:

Endpoints MUST ignore unknown or reserved control frame types.

14.4 Processing Rules

Control frames MUST be processed according to the following rules:

Authentication First

Control frames MUST only be processed after successful AEAD decryption and authentication.

Replay Protection

Control frames are subject to the same replay protection rules as data packets, including epoch and sequence number validation.

Ordering

Control frames MUST be processed in the order received. Implementations MUST NOT assume reliable delivery.

Idempotence

Control frame processing SHOULD be idempotent where possible. Duplicate control frames MAY occur due to packet loss or retransmission.

Failure Handling

If a control frame fails validation, the packet MUST be discarded and MUST NOT affect session state.

14.5 Control Frames vs. Reliability

PALISADE does not require reliable delivery of control frames.

• Implementations MUST NOT assume that a control frame is received exactly once.
• Missing control frames MUST NOT cause protocol deadlock.
• Periodic rekeying, time-based triggers, or resumption MAY recover from missed control frames.

Optional mechanisms for improving control frame reliability (e.g., acknowledgments or retransmissions) MAY be implemented but are not part of the core protocol.

14.6 Security Properties

Control frames inherit the following security properties:

• Confidentiality — Control semantics are encrypted.
• Integrity — Control frames are authenticated by AEAD.
• Replay Resistance — Control frames cannot be replayed outside the replay window.
• Anti-Fingerprinting — Control frames reveal no plaintext metadata to the network.

14.7 Non-Normative Notes

• Control frame acknowledgments are OPTIONAL and defined outside the core protocol.
• Control frame sequencing, retransmission, and state tracking are implementation concerns.
• Deployments that require reliable control signaling SHOULD use implementation-level mechanisms described in Appendix X.9.