skip to content

Your peers won't all deploy TCP-AO on 300 BGP sessions - how do you allocate blind-injection defence?

level: principalimportance: nice to knowfreq 22%

answer

  1. sort controls by whose consent they need
  2. unilateral first, negotiated second
  3. hop distance removes reach, not arithmetic
  4. keys mean rollover with every counterparty
  5. rank the tail by consequence, not count

basics

~20 s

Spend unilateral hardening everywhere first because no peer has to agree to it, buy hop-count checking on every peer who will accept a change window, and reserve keyed per-segment authentication for the sessions whose loss actually hurts and where you control both ends.

solid answer

~50 s

Sort the controls by who has to consent. Randomising your ephemeral port range and advertising a modest receive window on low-volume control sessions are unilateral, cost nothing operationally, and multiply the guess space - do those across all 300. Hop-count checking, where each side sends at maximum time-to-live and refuses segments that arrive with fewer hops remaining, removes the off-path attacker's reach entirely, but it needs both ends configured; it is a one-line change with no key material, so it is the realistic ask in a peer change window. Keyed per-segment authentication removes the attack outright but carries a shared secret with every counterparty, rollover coordination, and platform support on both sides - that is a contract-level conversation, so spend it where you own both ends and on the handful of peers whose session loss is genuinely material. The organisational point is that you cannot mandate anything to a peer, so the plan has to work at partial adoption.

go deeper

for a junior

Know that some protections need both ends to agree and some do not, and that the ones needing no agreement are the ones you can actually deploy everywhere.

for a middle

Explain what each control class removes: a wider guess space, an attacker's ability to reach the session from off-path, or the value of a correct guess altogether.

for a senior

Show you would differentiate window and hardening policy between bulk data paths and low-volume control sessions rather than applying one default across the estate.

for a principal

Own the allocation argument: coordination is the scarce resource, partial adoption is the normal end state, and differentiated assurance with a written residual beats a uniform plan that never lands.

## Why this is a judgment call and not a configuration task Every technically strongest answer here - authenticate each segment with a shared key - depends on an organisation you do not control agreeing to do work for you. Three hundred peering relationships mean three hundred counterparties, each with its own change process, platform constraints and appetite. Any plan that only works at full adoption is not a plan. So the decision is an allocation: where does the coordination budget go, and what do you deploy that needs no coordination at all? ## Sort the control classes by consent required **Needs nobody's agreement.** - *Ephemeral source-port randomisation.* Widens the one part of the four-tuple an attacker cannot look up, adding roughly sixteen bits to the search when the range is wide and unpredictable. Narrow or sequential ranges throw this away for free. - *A modest advertised receive window on low-volume control sessions.* A routing session exchanges updates and keepalives, so it does not need a megabyte of window. Cutting the window is a direct multiplier on the sequence search - the same division that made the attack cheap works in reverse - and it costs a control session no throughput. It would be a real trade on a bulk replication link, which is exactly why the policy should differentiate the two rather than apply one default everywhere. **Needs a change window on both sides but no shared secret.** - *Hop-count checking.* Each side sends with the maximum time-to-live and refuses segments arriving with fewer hops remaining than expected. For a directly connected peer, a forged segment from anywhere else on the internet cannot arrive with the required value, so the off-path attacker's reach is removed rather than their arithmetic being made harder. No keys, no rollover, no secret to leak; the cost is one coordinated change and an accurate expectation of hop distance, which is why multi-hop sessions need more care. **Needs a shared secret and a lasting relationship.** - *Keyed per-segment authentication.* Every segment carries an integrity value computed with a key both ends hold. A forged segment is discarded regardless of tuple, sequence or window, so the attack class ends. The price is real: agreeing and exchanging a secret with each counterparty, supporting rollover without dropping the session, matching platform support at both ends, and an inventory that stays accurate for years. Multiply by three hundred and it is an operations programme, not a change. ## The allocation that follows 1. **Deploy the unilateral items estate-wide, immediately.** Nothing to negotiate, so there is no argument to lose. This is also the answer to "what did we do about it this quarter" that does not depend on anyone else. 2. **Ask for hop-count checking as the default in every peer change window.** It is cheap enough that most peers say yes, and it is the highest value per unit of coordination. 3. **Do keyed authentication first where you own both ends.** Internal sessions and replication links inside your own fleet have no counterparty problem at all; refusing to do them because the external programme is hard is the common inconsistency. 4. **Then rank external peers by consequence, not by count.** A handful of sessions carry most of the routes and most of the downstream impact. Buy authentication there, and accept a lower assurance on the long tail rather than pretending uniform coverage is coming. ## What to say to the peer who refuses Refusal is a legitimate answer from them, and the plan must survive it. State the residual clearly: this session remains vulnerable to a disruptive off-path actor who guesses a value inside the receive window, and the consequence is a teardown and reconvergence, not a compromise of data. Then take the unilateral measures that apply to your side and record the acceptance where it belongs, rather than treating a refusal as an unresolved task that quietly never closes. ## The traps this question is set for - **Answering with the strongest control only.** "Deploy authenticated segments everywhere" ignores the consent problem and is why the question mentions three hundred sessions. - **Treating stack hardening as the finish line.** Exact-match reset checks raise the cost enormously, and they neither authenticate the sender nor cover in-window data. - **Applying one window policy to every flow.** The right window for a bulk data path is wrong for a control session and vice versa; a single default is the decision that made the attack cheap in the first place. - **Uniformity as a goal.** With counterparties who can refuse, differentiated assurance by consequence is the honest target, and saying so is the principal-level move.

  • A peer refuses everything. What do you actually change on your side?
    Randomise your ephemeral port range, advertise a modest receive window on that low-volume session, and keep your stack's hardened reset handling current. Those are all one-sided. Then state the residual plainly - a disruptive off-path actor can still force a teardown and reconvergence - and get that accepted as a decision rather than leaving it as an open item nobody owns.
  • Why start with the sessions where you own both ends?
    Because they have no counterparty problem, so the only cost is your own operations. Internal routing sessions and replication links inside a fleet are exactly the long-lived, high-window flows this attack likes, and doing them proves the key-rollover process works before you ask three hundred outsiders to depend on it.
  • How do you defend spending on this at all when no such teardown has happened to you?
    Frame it by consequence and cost, not by incident history. One accepted packet ends a session and forces reconvergence across everything downstream, the attacker needs no foothold and installs nothing, and the unilateral half of the plan costs a configuration change. The expensive half is then scoped to the few sessions whose loss is genuinely material.

saying these in an interview costs you the question

  • Answers only with the strongest control and ignores consent
  • Assumes peers can be mandated to configure anything
  • Applies one receive-window default to every flow
  • Treats stack hardening as authentication of the sender
  • Chases uniform coverage instead of ranking by consequence

context

resolving links…