STUN/TURN Endpoint Cache Poisoning via Malicious Peer Relay Claims

[JamesEjembi]

Problem Statement / Feature Objective

The STUN/TURN relay endpoint cache accepts binding updates from any peer without authenticating the relay-origin claim. A malicious node can poison the cache by advertising itself as a relay for arbitrary target peers, causing traffic to be misrouted through the attacker's node.

Technical Invariants & Bounds

• Cache entry TTL: 300s (configurable 60-600s).
• Max cached endpoints per peer: 16.
• Poisoning detection: >5 incorrect relay claims within 60s triggers blacklist.
• Relay authentication: must present a signed ticket from the relay registry.
• Cache size limit: 10,000 entries total.

Codebase Navigation Guide

• src/net/relay/endpoint-cache.rs — cache read/write operations.
• src/net/relay/relay-registry.rs — authoritative relay registry.
• src/net/relay/stun-bind.rs — STUN binding request handler.
• src/attestation/relay-ticket.rs — signed ticket generation and verification.

Implementation Blueprint

1. In relay-ticket.rs, implement a ticket scheme: relay signs (relay_id, target_id, epoch, expiry) with its Ed25519 identity key.
2. In endpoint-cache.rs, reject PUT operations where the ticket verification fails or the ticket's target_id does not match the cache key.
3. Add a poison-penalty counter: on failed verification, increment peer penalty; at threshold, drop all entries from the offending peer.
4. In stun-bind.rs, attach a ticket to every STUN binding response before forwarding to cache.
5. Fuzz test: submit 1,000 malicious binding updates with forged tickets, verify zero cache-poisoning successes.

[Cyber-Mitch]

Hi, I'd like to apply for this issue.

This is a strong fit — cache-poisoning via unauthenticated relay claims is a real network-security vulnerability class, and getting the ticket-verification and blacklist logic exactly right is where I'd focus, since a subtle gap here (e.g. verifying the signature but not binding it to the right target) reintroduces the same attack in a slightly different form.

A few things I'd treat as load-bearing:

Ticket binding must be exact — verifying the Ed25519 signature alone isn't sufficient; the ticket's target_id has to match the cache key being written, or a relay could present a validly-signed ticket for peer A while attempting to poison the cache entry for peer B. I'd test this as its own explicit case, separate from plain signature-forgery rejection.
Epoch/expiry enforcement — a validly-signed but expired or stale-epoch ticket should be rejected just as hard as a forged one, since a captured-and-replayed old ticket is a realistic attack too.
Poison-penalty counter correctness — the >5-incorrect-claims-in-60s threshold needs a sliding or windowed count, not a naive counter that never resets, or a peer could get permanently blacklisted from a handful of stale failures long after they've stopped, or conversely evade detection by pacing forged attempts just under the window.
Cache-eviction on blacklist — dropping all entries from an offending peer needs to actually remove poisoned state, not just block future writes, since the existing damage (misdirected entries already cached) would otherwise persist even after detection.
Cache size and per-peer limits — enforced independently of the poisoning logic, so a flood of valid binding updates can't exhaust the 10,000-entry cap as a separate DoS vector.

Implementation order: relay-ticket.rs signing/verification first (this is the security-critical primitive everything else depends on) → wire rejection into endpoint-cache.rs PUT path, including the target-id binding check → penalty counter and blacklist eviction → stun-bind.rs ticket attachment → the 1,000-forged-ticket fuzz test asserting zero successful poisonings, plus a legitimate-traffic test proving the fix doesn't reject valid relay updates.

I'll complete the task within a day of assignment, and I'll open a draft PR early — once ticket verification and the target-binding check are green — so the core authentication primitive gets review before I finalize the penalty logic and fuzz suite.

Happy to adjust based on your priorities.

[Cyber-Mitch]

You did use the OSS bot to assign me the issue though @JamesEjembi

[github-actions]

@Cyber-Mitch you are already assigned to this issue.

[Cyber-Mitch]

@Cyber-Mitch you are already assigned to this issue.

Yes i know, but i didn't get a notification from the grant fox oss bot, it's supposed to notify me