ETS-backed CREATE PERMISSION allowlist keyed by allocation 5-tuple and peer IP.
What problem this solves
Relay traffic to a peer is denied unless that peer's IP was granted via CreatePermission. This table records allowed peers and timestamps so the media and relay ingress paths can check permissions in O(1) without calling into the allocation GenServer on every packet.
Each entry is {{normalized_tuple5, peer_ip}, monotonic_ms}. The :proto
field is wildcarded so permissions match the allocation regardless of
control transport.
Internal
Runtime infrastructure; written by CreatePermission / allocation workers,
read by DataPlane and RelayIngress.Worker.
RFCs
- RFC 5766 - permissions (pt.8, pt.9)
Summary
Functions
Returns whether peer_ip may send traffic to the allocation identified by tuple5.
Returns true when permission is missing or last granted at least min_age_ms ago.
Grants relay permission from tuple5 to peer_ip. Returns :ok.
Creates the public permissions ETS table if it does not exist.
Revokes permission for a single peer on tuple5. Returns :ok.
Revokes every peer permission for tuple5. Returns :ok.
Functions
Returns whether peer_ip may send traffic to the allocation identified by tuple5.
Returns true when permission is missing or last granted at least min_age_ms ago.
Used to throttle Client.touch/3 on the media path. Default interval is 60s.
Grants relay permission from tuple5 to peer_ip. Returns :ok.
Creates the public permissions ETS table if it does not exist.
Revokes permission for a single peer on tuple5. Returns :ok.
Revokes every peer permission for tuple5. Returns :ok.