10. Traffic Shaping Modes (Normative)

PALISADE supports optional traffic shaping to reduce information leakage from packet size and transmission timing. Traffic shaping behavior is negotiated during the handshake or configured by server policy and applies uniformly to all encrypted packets within a session.

Traffic shaping affects only packet padding and transmission timing. It does not modify cryptographic processing, nonce construction, replay protection, or packet validation rules.

10.1 General Requirements

The following requirements apply to all traffic shaping modes:

• Traffic shaping MUST NOT alter packet wire format.
• All packets, including dummy packets, MUST be valid PALISADE packets.
• All packets MUST use correct nonce construction, epoch handling, and sequence numbers.
• Dummy packets MUST be indistinguishable from real packets prior to successful AEAD decryption.
• Dummy packets MUST be marked using a reserved encrypted-header stream identifier (stream_id = 0xFF) and MUST be discarded by receivers after authenticated decryption.
• Traffic shaping behavior MUST NOT weaken replay protection or forward secrecy.
• Traffic shaping is applied after encryption decisions but before transmission.

10.2 Mode 0 — Disabled (Default)

Behavior

• No padding beyond protocol-required fields is applied.
• Packets are transmitted immediately when available.
• No dummy packets are generated.

Requirements

• Mode 0 MUST be the default if no traffic shaping mode is negotiated.
• Implementations MUST NOT introduce artificial delays or padding in this mode.

10.3 Mode 1 — Randomized Padding

Mode 1 provides lightweight protection against simple packet-size fingerprinting by adding randomized padding to each packet.

Behavior

For each transmitted packet:

• A padding length is selected uniformly at random from a configured range.
• Padding bytes are appended to the payload before encryption.
• The padding length is recorded in the encrypted header.

Requirements

• Padding bytes MUST be generated using a cryptographically secure random source.
• Padding length MUST be uniformly distributed within the configured bounds.
• Padding MUST NOT contain recognizable or deterministic patterns.
• Padding bytes MUST be ignored by the receiver after authenticated decryption.
• Mode 1 MUST NOT introduce artificial transmission delays.

10.4 Mode 2 — Constant-Rate Transmission

Mode 2 provides resistance against packet-size and timing analysis by enforcing a constant transmission rate.

Behavior

• Packets are transmitted at a fixed rate defined by configuration.
• When no application data is available, dummy packets are transmitted.
• All packets transmitted under Mode 2 MUST conform to a fixed or bounded packet size.

Requirements

Packet Transmission

• Packets MUST be transmitted at the configured rate, subject to bandwidth constraints.
• Real application packets MUST be transmitted without artificial delay.
• Dummy packets MAY be transmitted only when necessary to maintain the target rate.

Dummy Packets

• Dummy packets MUST be encrypted and authenticated identically to real packets.
• Dummy packet payload bytes (if any) MUST be cryptographically random.
• Dummy packets MUST use valid epoch_id and seq values for the current sending direction.
• Dummy packets MUST be indistinguishable from real packets until successful AEAD decryption.
• Dummy packets MUST set EncryptedHeader.stream_id = 0xFF (STREAM_DUMMY).
• Receivers MUST discard packets with stream_id = 0xFF after authenticated decryption.

10.5 Bucketed Packet Sizes (Mode 2)

When Mode 2 is active, packet sizes MAY be constrained using bucketed size selection.

Requirements

• Packet sizes MUST be selected from a negotiated or configured set.
• Real packets MUST be padded to a valid bucket size.
• Dummy packets MUST also use valid bucket sizes.
• Plaintext larger than the selected bucket size MUST NOT be transmitted.
• If size variation within a bucket is permitted, the variation MUST be cryptographically random and bounded.
• Bucket sizing applies to the total encrypted payload length (EncryptedHeader || payload_data || padding).

10.6 Bandwidth and Abuse Constraints

To prevent resource exhaustion and denial-of-service amplification, the following constraints apply:

• Implementations MUST enforce a maximum total transmission bandwidth.
• Dummy packet generation MUST be suppressed if bandwidth limits are reached.
• Real traffic MUST NOT be dropped solely to maintain traffic shaping guarantees unless explicitly configured.
• Traffic shaping MUST NOT cause unbounded CPU, memory, or bandwidth consumption.

10.7 Interaction with Other Protocol Features

Replay Protection

• Dummy packets MUST participate fully in replay protection.
• Replay windows MUST NOT distinguish between real and dummy packets.

Epoch Transitions

• Traffic shaping behavior MUST NOT interfere with epoch transitions or overlap windows.
• Dummy packets MUST NOT extend the usable lifetime of old epoch keys.

Security Properties

Traffic shaping MUST preserve:

• Confidentiality
• Integrity
• Replay protection
• Forward secrecy

Traffic shaping is defense-in-depth and MUST NOT be relied upon as a primary security mechanism.

10.8 Negotiation and Policy

• Traffic shaping mode MAY be negotiated during the handshake.
• The server MAY enforce traffic shaping policies regardless of client preference.
• Mode changes MUST apply uniformly to the entire session unless renegotiated.

10.9 Summary

Traffic shaping enhances resistance to traffic analysis while preserving protocol correctness and cryptographic guarantees.