Frozen-envelope UDP path exceeds the documented amplification budget; telemetry records a constant #33

New Issue

2026-08-22T23:29:00+02:00

Kyuubi commented

2026-08-22 23:29:00 +02:00

Parent: #1
Identified by: v1.0.0 pre-release security review (2026-08-22). Severity: minor — not practically exploitable, but a code/doc divergence in a documented security invariant.

Finding

The 192-char padding on the LiteNetLib NAT token is what holds the native path to the documented ≤2.0 response-byte ratio (docs/architecture/0003-state-privacy-availability-and-budgets.md, docs/contracts/udp-v1.md:51). The frozen envelope carries no such padding: an IPv4 ClientPresence envelope is ~73 bytes yet completes the same two ~217-byte introductions — ~5.9× per completing datagram, ~2.9× toward a single spoofable source (NatMediationProcessor.cs:98-139, 277-306; RendezvousUdpCodec.cs:13,56; NatPunchRequestTokenCodec.cs:50).

Not exploitable in practice: introduction is one-shot per attempt (InMemoryEphemeralRendezvousStore.cs:712-754), so every ~217 reflected bytes costs the attacker a full HTTPS join-attempt round trip — there is no usable amplifier. But the documented invariant is not what the code enforces.

Related: the amplification metric cannot detect this or any future regression — NatMediationProcessor.cs:82-88, 181-187 records response bytes as the constant 2 * ContractLimits.UdpDatagramMaxBytes rather than actual emitted bytes.

Outcome

Either pad/bound the frozen-envelope path to restore the documented ≤2.0 ratio, or amend the ADR/contract doc to state the real per-path budgets — and in both cases record actual emitted response bytes in the amplification telemetry so the budget is observable.

Acceptance criteria

Documented budget and enforced behavior agree for every UDP request path.
Amplification metrics reflect real bytes; a regression past the budget is visible in telemetry.
A test pins the worst-case response-bytes-per-request-byte ratio per path.

Parent: #1 Identified by: v1.0.0 pre-release security review (2026-08-22). Severity: minor — not practically exploitable, but a code/doc divergence in a documented security invariant. ## Finding The 192-char padding on the LiteNetLib NAT token is what holds the *native* path to the documented ≤2.0 response-byte ratio (`docs/architecture/0003-state-privacy-availability-and-budgets.md`, `docs/contracts/udp-v1.md:51`). The frozen envelope carries no such padding: an IPv4 `ClientPresence` envelope is ~73 bytes yet completes the same two ~217-byte introductions — ~5.9× per completing datagram, ~2.9× toward a single spoofable source (`NatMediationProcessor.cs:98-139, 277-306`; `RendezvousUdpCodec.cs:13,56`; `NatPunchRequestTokenCodec.cs:50`). Not exploitable in practice: introduction is one-shot per attempt (`InMemoryEphemeralRendezvousStore.cs:712-754`), so every ~217 reflected bytes costs the attacker a full HTTPS join-attempt round trip — there is no usable amplifier. But the documented invariant is not what the code enforces. Related: the amplification metric cannot detect this or any future regression — `NatMediationProcessor.cs:82-88, 181-187` records response bytes as the constant `2 * ContractLimits.UdpDatagramMaxBytes` rather than actual emitted bytes. ## Outcome Either pad/bound the frozen-envelope path to restore the documented ≤2.0 ratio, or amend the ADR/contract doc to state the real per-path budgets — and in both cases record actual emitted response bytes in the amplification telemetry so the budget is observable. ## Acceptance criteria - Documented budget and enforced behavior agree for every UDP request path. - Amplification metrics reflect real bytes; a regression past the budget is visible in telemetry. - A test pins the worst-case response-bytes-per-request-byte ratio per path.

Kyuubi referenced this issue

2026-08-22 23:29:54 +02:00

Harden tenant isolation, rate limits, replay defense, parsers, and overload behavior #15

Kyuubi referenced this issue

2026-08-22 23:29:58 +02:00

Add privacy-safe observability, health, audit, and operator controls #16

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: HeiKyu/Rendezvous#33