RPKI, CPM filtering and management-plane cleanup in one maintenance window
A security audit of a 900-node MPLS network found: all iBGP and eBGP sessions use TCP MD5 only; two eBGP sessions to a transit provider carry the full IPv4 table (about 950,000 prefixes) with no maximum-prefix limit; SNMPv2c with community public is enabled on 60 nodes; Telnet is enabled on 12 legacy 7210 SAS; CPM filters exist on only four core PEs and each ends with an implicit default permit. The operator must deploy RPKI origin validation within 30 days without dropping customer traffic. The customer-facing peers announce many /24s, and the upstream transit provider occasionally leaks RPKI-invalid prefixes when its local cache is stale. One engineer suggests enabling reject-invalid globally on day one and removing Telnet in the same maintenance window.
1. Plan the RPKI origin validation rollout and explain how you would treat NotFound and the provider's invalid leaks.
Read the worked answer
The dominant risk is not invalid prefixes, it is NotFound. A large share of the table, and of this operator's customer space, will have no covering ROA. Any policy that treats NotFound as rejectable will drop legitimate customer routes on day one. Accept NotFound throughout.
Rollout:
- Stand up two independent validator caches so a validator outage cannot cause policy to flap, and confirm both are feeding the routers.
- Enable validation with logging only, no dropping, for at least one full BGP cycle; export per-peer counts of Valid, Invalid and NotFound and compare the invalid set against expectations from the known leak history.
- Enable reject-invalid on customer-facing eBGP sessions first. Customer announcements should be Valid or NotFound, so this is where the immediate protection sits and where a mistake is most visible and easiest to reverse.
- On the transit sessions, reject-invalid as well but with a documented exception route-map and a monitoring trigger, and coordinate with the provider: on a stale cache they may announce prefixes that are valid globally but invalid against a current ROA, and rejecting those can remove reachability to third parties. Keep a pre-built policy that can fall back to accept-all within one commit.
- Add per-peer maximum-prefix before any of this, so a leak cannot exhaust memory while policy is being tuned.
2. How would you design the CPM filter change on the PEs, and what makes the current implicit default permit dangerous?
Read the worked answer
The implicit permit is dangerous for two reasons. It provides no protection, so the filter gives false assurance; and if someone removes it and adds a default drop without enumerating the control plane, the node loses BGP, OSPF or BFD and looks like a hardware failure. Both failure modes are common.
Design:
- Enumerate explicitly, per address family: TCP 179 from every configured BGP peer address, OSPF protocol 89 on core interfaces, UDP 3784 and 4784 for BFD, NTP, SNMP, SSH, and the ICMP types needed for PMTUD. Include IPv6 entries even if the node looks IPv4-only; an unpermitted protocol can still reach the CPM.
- Order matters: precise accepts for peer-specific traffic first, then broader management-source accepts, then a final drop. Do not rely on a deny-anywhere statement later in the filter to catch what an earlier permit already allowed.
- Prefer prefix-list or apply-path style matching generated from the configured peers, so that adding a BGP neighbor later does not silently require a filter edit.
- Roll out on one non-critical PE with an out-of-band console session open, and use a confirmed commit or scheduled rollback so that a lockout self-heals. Apply to the management interface separately from the CPM path; locking yourself out of one should not remove the other.
- Note that a CPM filter protects the node, not the transit data plane, and does nothing for traffic that is forwarded rather than destined to the box.
3. Evaluate the proposal to enable reject-invalid globally and disable Telnet in the same maintenance window.
Read the worked answer
Bad idea on both counts, for the same underlying reason: unrelated changes with different blast radius and different rollback paths get bundled.
Bundling makes diagnosis impossible. If access to a device disappears mid-window, nobody can tell quickly whether the CPM filter, the RPKI policy or the Telnet change caused it, and each requires a different rollback.
Telnet on 12 legacy 7210 SAS should be removed, but in its own window and in the right order: out-of-band access first, then verified SSH credentials and key distribution, then disable Telnet on one node, confirm access, then the rest. If a legacy release has a broken or slow SSH implementation, you want to discover that on one node, not while also debugging a routing policy.
Reject-invalid on day one globally is also wrong even as a standalone change: it will drop customer space whose announcements are NotFound or temporarily invalid. Enable it staged, per peer, logging first, as described earlier.
If a single window is unavoidable because of change-control constraints, order the work so that each step is independently reversible and none can remove your management path: RPKI in logging-only mode, then CPM filter on a canary, then Telnet removal after OOB access is proven on the same node. Never let the step that removes your access be the one bundled with the step that is hardest to roll back.