I85PREP
⌘ K
Telecom Professional Qualification study materials
Telecom Professional Qualification study resources

A Customer Sub-Prefix Takes the Mail and DNS Servers Off-Net

Telecom Professional Qualification · Put your knowledge to work in context.

All case studies

A Customer Sub-Prefix Takes the Mail and DNS Servers Off-Net

Meridian ISP (AS 64520) holds 203.0.113.0/22, published as a ROA with maxLength /22. It is dual-homed to Transit-A, which performs RPKI route origin validation, and Transit-B, which does not, and peers at one IXP. A colocation customer (AS 65099) is single-homed to Meridian and, during a router migration, began announcing 203.0.113.128/25 - a sub-prefix of Meridian's own aggregate - from a new edge router with a missing outbound prefix-list. Within four minutes, 70% of inbound traffic to Meridian's mail and authoritative DNS servers in that /25 shifted onto the customer's 100 Mbps link. Latency to those services rose from 12 ms to 400 ms and some users see timeouts. Traceroutes from Transit-A show the /25 arriving as RPKI invalid and dropped, so reachability now differs by upstream. The customer's NOC insists the announcement is deliberate traffic engineering and asks Meridian to raise the ROA maxLength to /25.

1. Explain precisely why traffic moved and why reachability is now inconsistent across upstreams.

Read the worked answer

Two independent mechanisms are at work.

1. Longest-prefix match. Every router that receives both 203.0.113.0/22 from Meridian and 203.0.113.128/25 from AS 65099 installs the /25 for that half of the range, because /25 is more specific than /22 regardless of AS-path length. Meridian's own traffic-engineering attributes (AS-path prepending, MED, communities) are irrelevant against a longer prefix. About half the address space is affected by prefix length alone; the 70% figure reflects that the mail and DNS servers sit inside the /25 and that most of the inbound paths converged on the new announcement within four minutes.

2. RPKI origin validation. Meridian's ROA says origin AS 64520, maxLength /22. An announcement of 203.0.113.128/25 from AS 65099 is therefore Invalid: wrong origin and too long. Transit-A, running ROV, discards it and keeps the /22. Transit-B has no ROV, so it accepts and propagates it. Result: part of the Internet reaches those servers over the /22 via Transit-A and part over the 100 Mbps link via Transit-B - hence the traceroute divergence and the intermittent timeouts.

The 100 Mbps customer link cannot carry the mail and DNS load, so queueing produces the 12 ms to 400 ms jump; the timeouts are TCP retransmits, not packet loss on the aggregate.

2. Set out your response in order of execution and state whether you would raise the maxLength.

Read the worked answer

Execution order:

  1. Stop the announcement at source. Apply an inbound prefix-filter on the eBGP session to AS 65099 permitting only the customer's own registered space, plus an inbound max-prefix limit and a route-map denying any prefix from Meridian's own aggregate. Do this before any outbound engineering - the leak must stop growing.
  2. Verify withdrawal. Check the looking glasses of Transit-A, Transit-B and two IXP peers that the /25 is gone and the /22 is restored, then confirm latency and error rates on the mail and DNS servers.
  3. Ask the two accepting upstreams/peers for ROV and IRR-based filters on their sessions to Meridian; this is defence in depth, not the fix.
  4. Restore customer service, then issue an incident note internally and, if the customer's traffic was affected by the 100 Mbps bottleneck, to the customer's account team.

Do not raise maxLength to /25. The maxLength is a security control that says 'I will never originate anything longer than a /22.' Raising it to /25 makes every /25 inside the block a valid announcement for any hijacker who can originate it, permanently. It converts a self-inflicted leak into a permanent attack surface in order to solve a problem that is fixed in five minutes by a prefix filter.

If Meridian genuinely needs a /25 later for traffic engineering from its own AS, it should originate it from AS 64520 with a matching ROA and a documented change record - not by widening the existing authorisation for the whole block.

3. What preventive controls would you put in place, and how would you verify them before the next change window?

Read the worked answer

Controls, layered:

  • Customer and peer sessions: inbound prefix filters generated from IRR objects, inbound max-prefix limits with an alert threshold at 80%, and an explicit deny for any prefix inside Meridian's own aggregate (a self-AS check on AS_PATH, plus a prefix-list).
  • Customer edges: default-originate towards single-homed customers that need only a default route; a customer should not be able to leak a table it does not have.
  • Route-leak prevention: enable the RFC 9234 'only-to-customer' capability on customer sessions where supported, and role-mark peer and provider sessions.
  • RPKI: keep ROV enabled on all Meridian routers, monitor Invalid counts as a security signal rather than only as a routing problem, and alert on any origin change for Meridian's own prefixes.
  • Change control: any edge-router migration requires a pre/post show bgp summary and advertised-route diff, plus a four-eyes check on the route-map; the migration that caused this should have failed the checklist at the missing outbound filter.
  • Monitoring: external BGP monitoring (a public looking-glass feed or a commercial BGPalerter-style service) alerting on any announcement of a more-specific inside your aggregate within 60 seconds.

Verification before the next window: run the checklist as a tabletop - deliberately originate a /25 from a lab session in the same ASN and confirm the filter blocks it, and confirm the alert fires. A control that has never been tested is an intention, not a control.