A partner announces prefixes over your site-to-site tunnel that the contract annex never listed — what limits their reach, and what does holding that limit cost?

## An announcement is a request When a partner's gateway advertises prefixes across a site-to-site tunnel, it is telling your routers *where to send traffic*. Nothing about the announcement is authoritative for you. Your side decides what it accepts, and that decision — not the annex in the contract — is the actual limit of the relationship. The failure this question aims at is a competent engineer answering that the reach is defined by the agreement, or by the tunnel's traffic selectors, and stopping there. The agreement is a document. The selectors are one input. The enforceable limits are the ones configured on your side. ## Three separate controls, three separate directions Keeping the directions straight is most of the answer. | Control | Governs | Failure if absent | |---|---|---| | Inbound prefix filter (or static routes only) | Which destinations *your* traffic is routed toward the partner | An over-broad or default announcement pulls your outbound traffic into their estate | | Source-address filter on the tunnel interface | Which claimed source addresses you accept *from* the partner | Their host sources from an address range your rules trust, sidestepping policy keyed on source | | Extranet zone policy | Which of your destinations and ports the partner may reach | The whole relationship collapses into one permissive permit | A partner announcing `10.42.0.0/16` when the annex agreed `10.42.7.0/24` may simply be sloppy. A partner announcing a supernet that covers *your* internal ranges, or a default route, is a much more interesting event: it means your traffic destined for those ranges is now routed to them. Whether that is a misconfiguration on their side, an intruder inside their estate steering traffic, or a managed provider fat-fingering a template that serves several of their customers at once, the mitigation is identical and it is on your side. ## What the accepted-route filter should be For most partner relationships the right answer is not to run a dynamic routing session at all. A handful of static routes toward the tunnel, pointing at exactly the agreed prefixes, cannot be changed by anything the partner does. Where dynamic routing genuinely is needed — a partner with many changing subnets, a provider integration — accept only an explicit prefix list, cap the number of accepted prefixes so a leak becomes an alarm rather than a routing table, and refuse anything covering your own address space or a default route outright. The complementary half is the source filter. Accepted routes say where you send; they say nothing about what you accept. A packet arriving from the tunnel carrying a source address inside your own estate should be dropped on sight, because there is no legitimate reason for it and it is exactly what someone does to satisfy a rule written on source. ## The price, honestly stated Every tightening here creates work that never ends: - **Ownership.** Somebody has to own the prefix list per partner. When that person leaves, the list ages into folklore that nobody dares change. - **Change latency.** The partner adds a subnet for a new service; your filter denies it; the business feels it as your firewall breaking their project. You need a documented path with an SLA, or people will route around you by widening the filter permanently. - **Outage risk on the tighten.** The first time you replace a `/16` with the agreed `/24`, you find the quarter-end batch job that used a host outside the agreed range. Tightening is safest done by logging first — run the narrow rule in a monitoring posture, or diff observed flows against the proposed filter — rather than cutting straight over. - **Evidence.** In a third-party risk review you will be asked to show what the partner can reach. The prefix list plus the zone policy *is* that evidence; the annex is not, and saying so is what separates a real answer from a compliance one. ## What the limit does not buy you Route and source filtering constrain **reach**, not intent. Within the permitted prefixes and ports the partner — or whoever is inside them — has whatever access the relationship needs, and that is often enough to matter. Route control is the cheapest large reduction available, not a substitute for what sits at the destination. ## Interview framing State the principle first: the accepted-route filter is the real reach limit and the annex is paper. Then show both directions, then name the maintenance cost and who owns it. A candidate who names the cost is describing something they have actually run.