Testing IP-Based Trust During a Network Path Change: Prove Which Allowlists Fail Open

TL;DR

When a cloud region, egress NAT, or transit provider changes the path your traffic takes, every control that trusts a source IP keeps matching — but the address behind the rule may no longer be the one you hold, or may no longer be yours at all. Test it by sending the same authenticated request from the old path and the new one to each endpoint that carries an address exception, then compare both the responses and the target-side log lines. Proof of impact is an authorization decision made on an address whose registered owner has changed, with both ends of the transaction captured. Announced cutovers give you a low-risk window to run that test before a real path change finds the gap for you.

What this is

IP-based trust is any access decision that resolves to an address comparison instead of a verified identity: an application allowlist, a WAF exception, a security group, a partner firewall, an SSO named location, a mail relay rule, or a monitoring suppression keyed to a source range.

A path change is any planned or unplanned event where traffic between your workloads and their dependencies enters and exits through a different route — a new NAT gateway, a new region, a new transit provider, or a deliberate cutover exercise. The AWS European Sovereign Cloud independent-operation exercise is a public example of the announced kind: the published account describes the partition running without its usual global network dependency and the results being released as verifiable technical and operational evidence (AWS Security Blog).

For a researcher, that framing is the useful part. A sovereign or regional cutover is a claim backed by an observation. Your own stack makes smaller claims of the same shape every day — "only our gateway can call this", "only internal ranges reach the admin panel", "traffic from the EU stays in the EU" — and each one is falsifiable with two clients and a diff.

Why it matters

Address-based trust is cheap to write and expensive to verify, so it survives long past the deployment that justified it. The rules most likely to break silently when a path changes:

• Partner and vendor allowlists that list your egress IP. If the path changes and the address is released, the partner still trusts an address you no longer control.
• Internal applications that treat RFC 1918 space or a specific CIDR as pre-authenticated.
• SSO conditional access / named locations that gate admin roles on a country or a range.
• WAF and API gateway exceptions keyed to an operator's home or office address.
• Mail controls — relay allowlists, SPF entries, and IP reputation inherited from an address block.
• Telemetry and residency filters that suppress "known partner" traffic by IP, or assert geography from a geo-IP lookup rather than from the destination itself.

Two failure modes follow, and one of them ratchets. Fail-closed breaks a business flow, and the usual fix is to widen the rule until service returns — a permanent opening created under time pressure. Fail-open is worse: the request succeeds because the address matched, and nobody looks again. The widest, oldest, least-reviewed rules in most estates were created during an incident window exactly like the one a path change produces.

How it works

The mechanism is a stored address with no ownership check. Someone captures an address at deployment time and writes it into a rule; nothing in the system re-verifies that the address still belongs to the party it was meant to name. Change the route and the mapping between address and identity breaks on both sides at once: your egress moves, and the released address returns to a pool where it can be reassigned to someone else — while the rule that trusts it stays exactly as written.

The test is a two-client comparison, not an attack. You are checking whether the decision survives a change of path.

1. Build the pair. Client A takes the normal path. Client B takes the alternate — a test instance in the new egress subnet, a host in the range the provider published for the cutover, or a temporary NAT gateway stood up for the window. Keep identity, headers, and payload identical; the path is the only variable.
2. Replay the same request from both clients during the window and immediately after it, so you capture the transition and not just one state.
3. Capture both ends. The request and response as you sent it, and the target-side log line as the target recorded it, with the source address it actually observed. One end alone is an anecdote.
4. Resolve ownership with an RDAP query (RFC 9082) for every trusted address at test time. This is the step that converts "it worked" into impact.

Deciding what you have:

• Client B gets the same privileged response as Client A with identical authentication, and the only rule that could have matched names an address whose registered owner is now someone else → finding.
• Client B is denied and Client A is allowed → availability finding; keep it, because the remediation will be to widen the rule.
• Both are denied for unrelated reasons → the rule was never load-bearing; deprioritize it.

The strongest evidence is not "the request succeeded". It is "the request succeeded because of an address, and the registry says that address no longer belongs to us." Attach the request/response pair, the rule as configured, and the ownership record, and a second researcher can check it without repeating your window.

Detection and response

Telemetry worth collecting across the window, in the order it usually pays off:

• Flow logs and egress proxy logs — destinations and source addresses before, during, and after. The diff is the dependency map.
• Resolver logs — the external names your workloads look up during the window. A name that still resolves to an address outside the claimed boundary is a dependency, whatever the architecture diagram says.
• TLS SNI from the egress proxy — which third parties you actually spoke to, independent of DNS.
• Application auth logs — new source addresses appearing against sensitive endpoints, and which rule matched.
• WAF and gateway logs — every IP-exception rule that fired from an address not seen before.
• Cloud audit logs — security group, NACL, firewall, and named-location changes made during the window. This is where the temporary widening hides.
• Sign-in logs — conditional access decisions where the named-location evaluation flipped for a user who did not move.

What a defender checks afterwards: a before/after diff of every rule that names an address, the current registered owner of each of those addresses, an expiry date on anything widened during the incident, and an alert for any request to a privileged endpoint whose only matching rule is a source-address exception.

What to do

1. Inventory every decision that resolves to an address: application config, WAF, security groups, SSO named locations, partner firewalls, mail allowlists, and telemetry suppressions.
2. For each, record the address, the RDAP registrant, the reason it exists, and the date it was last verified. Anything unverified since its last change window is a candidate.
3. Schedule the A/B test against a real path change — a cutover, a migration, or an announced exercise — rather than simulating one in a lab where the routing is not the production path.
4. Run the pair on the highest-consequence endpoint first. One endpoint, two clients, same identity.
5. Capture the response, the target-side log line, and the RDAP record in a single evidence bundle, and write the finding as "this decision rests on an address, and here is who owns that address now".
6. Replace the trust: mutual TLS, signed short-lived tokens, private endpoints, or an identity-aware proxy. If you must keep an address rule, monitor the ownership record and set an expiry.
7. Treat any widening done to restore service as a finding with an owner and a removal date, not a config change.

FAQ

Is this just egress IP allowlisting? No. Egress allowlisting is one consumer of the assumption. The same failure appears in inbound WAF exceptions, security groups, SSO named locations, mail reputation, and monitoring filters — anything that stores an address where it meant to store an identity.

How do I test this without breaking production? Use the announced window and the alternate path the provider is already using, replay read-only or low-impact requests first, and keep the pair narrow: one endpoint, two clients, identical identity. You are comparing decisions, not load-testing.

Which is worse, fail-open or fail-closed? Fail-open is the security finding and fail-closed is the availability finding, but fail-closed is what creates the next fail-open. The widening done during the outage outlives the outage.

Can I rely on geo-IP to enforce residency or access policy? Only if you re-verify it when paths change. Geo-IP databases lag reassignments, and a rerouted path can present a different country for a user who has not moved — which breaks the policy in both directions.

Did the AWS exercise prove sovereignty for its customers? It produced verifiable technical and operational evidence that the partition can operate without non-EU dependencies, which is what AWS published and what regulated customers can take to their boards. A customer's own dependency and trust-rule testing remains a separate exercise, and the published window is the easiest time to run it.

Where this fits in a program

The hard part is rarely the request — it is keeping the evidence attached. A scanner candidate is not a finding until the request/response pair, the rule as configured, and the ownership record sit where a reviewer can check them. Trusteed's workspace is built around that last step, including a validation gate so an unproven hit does not reach an analyst queue as an alarm.

Sources

• AWS Security Blog — Inside a successful AWS European Sovereign Cloud exercise to demonstrate independent operation
• AWS Security Blog — AWS European Sovereign Cloud: Demonstrating an independent operation
• NIST SP 800-207 — Zero Trust Architecture
• European Commission — Cloud computing policy and sovereignty criteria
• RFC 1918 — Address Allocation for Private Internets
• RFC 9082 — Registration Data Access Protocol (RDAP) Query Format
• OWASP API Security Top 10
• Trusteed