PROTOCOL NOTES / 10

15 · Duplicates, stale media, hop exhaustion and rejected membership

Participants: Sender, Relay, Receiver

Implemented software · Physical qualification pending

Starting state

Actual valid keys/roles exist; duplicate or old packets, altered authentication, exhausted hops or unauthorized identities arrive as ordinary rejection cases.

Ordered events

  1. Sender → Relay

    Datagram or control arrives at scoped peer endpoint

  2. Relay → Relay

    Check role, structure, ride, hop authentication and replay

  3. Relay → Relay

    Check admitted source and SRTP replay/source age

  4. Relay → Receiver

    Only fresh authorized media can enqueue eligible branches

Fields and messages

Hop sequence, age, hops, source SSRC/index, signature source/seq; public versions and bounded lengths.

Authorization and invariants

Reject before source replay when role/hop proof fails; source authentication must succeed before forward. Admitted members share source symmetric keys and can impersonate media; no Byzantine guarantee.

Timers

Age 180 ms; egress 40 ms; source/hop replay windows; bounded control dedup.

Resource lifetime

Rejecting one packet cannot reset keys, replay, source clock or unrelated streams.

What the rider sees

Only bounded sanitized counters/events; no private packet/key logging.

Failure branches

Ordinary targeted authentication/replay tests are allowed; malformed-packet fuzzing, extended malformed campaigns, sanitizers and invasive memory stress remain excluded.

Resulting state

Rejected input does not deliver/flood speech or gain membership; valid subsequent traffic remains usable.

Evidence boundary

Existing valid-packet alteration, replay, age and membership functional tests; no excluded fuzz execution.

← All scenarios

Authority: RWCP v2 reviewed scenario catalogue, scenario 15. Public examples are synthetic. This guide is maintained against the private implementation; it does not imply access to its source.