Guardrails on ASN group refresh deltas #18

New Issue

2026-07-26T17:08:34+10:00

benvin commented

2026-07-26 17:08:34 +10:00

Problem. ASN expansion pipes third-party data (iplocate) directly into
fleet-wide permit rules. A bad upstream dataset, an account compromise, or an
actual BGP hijack reflected in the DB silently rewrites who
net:+asn_cloudflare admits — at whatever hour the 24h refresh fires.

Proposal.

Per-refresh delta cap: if membership changes by more than N% or M prefixes,
hold the update, keep last-good (consistent with §13 fail-safe semantics),
and alert.
Log every refresh with added/removed counts; expose the last delta per group
via the API for dashboards.
Optional allow-list of expected prefix ranges per group for the paranoid
tier.

Acceptance. A refresh returning a wildly different prefix set does not
reach any device without operator acknowledgement.

**Problem.** ASN expansion pipes third-party data (iplocate) directly into fleet-wide *permit* rules. A bad upstream dataset, an account compromise, or an actual BGP hijack reflected in the DB silently rewrites who `net:+asn_cloudflare` admits — at whatever hour the 24h refresh fires. **Proposal.** - Per-refresh delta cap: if membership changes by more than N% or M prefixes, hold the update, keep last-good (consistent with §13 fail-safe semantics), and alert. - Log every refresh with added/removed counts; expose the last delta per group via the API for dashboards. - Optional allow-list of expected prefix ranges per group for the paranoid tier. **Acceptance.** A refresh returning a wildly different prefix set does not reach any device without operator acknowledgement.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unkin/tomswallapi#18