Before an on-call may announce a BGP blackhole, what must the architect settle in writing?
answer
- the decision is commercial, not technical
- decide it in daylight, execute it in seconds
- a ceiling on how much may go dark
- the owners who refuse define the requirement
- an announcement needs an expiry and an owner
basics
~20 sWho is pre-authorised to take a named address offline, the longest prefix they may announce and who signs for anything coarser, the trigger and the withdrawal clock, and whether the organisation buys a granular upstream alternative for the addresses that may never go dark.
solid answer
~50 sThis lever completes the denial, so the decision it encodes is commercial, not technical, and it cannot be made at 03:00. Settle five things on paper. First, the trigger: what link utilisation and duration justifies pulling it. Second, the ceiling: the longest prefix every upstream reliably accepts, with anything coarser requiring a named authoriser. Third, consent: which service owners have agreed in advance that their address may be taken dark, and which have refused, because a refusal is a real answer that changes the plan. Fourth, the clock: how long an announcement stands before someone must re-decide, since an attacker can simply outlast it. Fifth, the alternative: whether to negotiate a granular upstream rule capability into the transit contract for the addresses on the refused list, and who funds it against the availability credits the coarse lever will cost.
go deeper
Understand that pulling this lever is a decision someone must have authorised in advance, and that your job during an incident is to execute within limits somebody else wrote, not to invent them.
Be able to describe what a usable runbook clause looks like: a numeric trigger, a maximum prefix length, the list of addresses cleared for sacrifice, and who to call for anything outside those bounds.
Demonstrate that you would walk the address list with owners before an incident, test the announcement at each upstream on a quiet day, and treat an untested arrangement as a capability you do not have.
Own the commercial framing: price the coarse lever's availability credits against the contract effort and limits of a granular upstream capability, and use the owners' refusals as the requirement that decides which one the organisation buys.
## Why this is a written decision rather than an operational one Every other network control is argued about on technical merit. This one is different, because using it means the defender deliberately finishes the outage the attacker started. An engineer cannot be asked to make that call alone, under time pressure, on behalf of a service they do not own. The architect's job is to move the decision into daylight and leave the on-call something narrow enough to execute in the forty seconds the mechanism actually takes. ## The five clauses **1. The trigger, expressed in numbers.** "Inbound utilisation above X percent of the access link for more than Y minutes, with the target confirmed as a single address on the pre-approved list." A trigger stated in numbers is auditable afterwards, and it prevents both hesitation and the opposite failure of reaching for the lever for a flood the link would have absorbed. **2. A prefix-length ceiling with a named escalation.** The runbook permits announcements no coarser than the longest prefix every upstream reliably accepts, verified by test rather than by their documentation. Anything wider takes an entire allocation off the internet, so it requires a named human who is awake and accountable. Encoding the ceiling in the automation is better than encoding it in prose, because prose does not stop a tired operator. **3. Pre-consent per address, including the refusals.** Walk the internet-facing address list with the owners and record, per address, whether the on-call may take it dark unilaterally. Some owners will say yes immediately, some will say yes with a notification obligation, and some will refuse, because their contract or regulator makes deliberate unavailability a different category of event from an attack. **The refusals are the most valuable output**, because they define the set of addresses for which you need another answer, and they convert a vague architectural worry into a funded requirement. **4. A withdrawal clock.** An attacker can stop, wait, and restart, so a blackhole left in place indefinitely is an outage the attacker gets for free. Write the review cadence, the criterion for withdrawing, the fact that withdrawal is a live re-test of whether the flood is still running, and who is allowed to re-announce. Without this clause the common failure is a blackhole nobody dares withdraw, discovered weeks later. **5. The purchase decision on granularity.** For the refused addresses, the alternative is a rule installed by the upstream that matches more than a destination, so it can shed the flood while leaving the address reachable. BGP Flowspec is the mechanism that distributes such rules between autonomous systems: it carries match components such as source and destination prefix, protocol, ports and packet length, with actions including rate limiting and discard. It costs a contract negotiation, because the provider must be willing to accept rules from you at all, will limit how many you may install and which actions are permitted, and will normally validate that the destination you filter falls inside a prefix you already originate to them. That negotiation is the thing nobody has done when the first flood arrives. ## Framing the money A principal-level answer prices both sides rather than asserting a preference: | Position | What you pay | What you get | |---|---|---| | Coarse lever only | Availability credits and reputational cost every time it is pulled; a permanent list of services that must never be attacked | Fast, cheap, works at any flood size, needs no contract | | Granular capability negotiated | Contract effort, possible recurring fee, a rule budget and per-provider limits, plus testing to keep it real | The refused addresses stay up under a flood shaped narrowly enough to match | The deciding input is the refusal list. If it is empty, the coarse lever plus a good address plan is a defensible strategy and buying more is hard to justify. If it contains the revenue-bearing service, then the organisation is one flood away from a choice it has already said it will not make, and that gap is the thing to escalate with a number attached. ## What to test, not assume All five clauses decay. Providers change communities and filters, addresses acquire new co-tenants, and an untested announcement is a hypothesis. Schedule a quiet-hours exercise that announces a harmless address at each upstream, confirms the discard from outside, and withdraws it, and treat a failure there as a finding rather than an inconvenience. The same applies to any granular capability you bought, which is worth exactly nothing if nobody has installed a rule through it in a year. ## The sentence that carries the whole answer The architect's deliverable is not a diagram. It is a short document that says, per address, who is allowed to finish the denial, how far the damage may extend, how long it may stand, and what the organisation bought instead for the addresses where the answer is no.
- A service owner refuses to pre-consent to their address being blackholed. Is that the end of the conversation?No, it is the start of a funded one. The refusal defines an address that needs an alternative, so you price two options for them: splitting the address so the sacrificeable parts stand alone, or negotiating a granular upstream rule capability that can shed a flood without taking the address down. If neither is funded, the documented outcome is that this service has no answer to a volumetric flood, which is a decision someone senior signs.
- Why does an announcement need a stated expiry rather than staying until someone notices?Because the attacker can stop and wait, and an announcement left standing hands them a free outage indefinitely. A stated review cadence forces someone to re-decide, and it names who withdraws and who may re-announce. Without it the usual failure is a discard nobody feels authorised to remove, found weeks later during unrelated troubleshooting.
- What would make you conclude the granular upstream option is not worth buying?An empty refusal list. If every internet-facing address either stands alone or has an owner content to lose it briefly, then a good address plan plus the coarse lever covers the risk, and the contract effort, rule limits and testing burden buy little. The calculation flips the moment a revenue-bearing service sits on an address nobody will consent to sacrifice.
saying these in an interview costs you the question
- Treats taking a service dark as an engineer's call alone
- Writes a runbook with no ceiling on prefix length
- Leaves the announcement standing with no review clock
- Assumes a granular upstream rule is available by default
- Never tests the arrangement outside a real incident