What RPKI Is,
What TTCL Broke,
and What You Must Fix

The internet has no central authority. No single body decides which IP addresses belong to whom. BGP — the protocol that carries every packet between autonomous systems — is built on trust. RPKI is the closest thing the internet has ever had to a verifiable chain of that trust. TTCL has opted out of it entirely.

What RPKI Actually Is — In Plain Language

When a router receives a BGP announcement — essentially a message saying "I, AS33765, can reach 41.59.0.0/16, send traffic my way" — that router has historically had no way to verify whether AS33765 is actually authorised to originate that prefix. It either believed the announcement or it didn't, based on prefix filters manually maintained by network engineers. Those filters are imperfect, out of date, and often simply absent. BGP, on its own, is a protocol built entirely on honour.

Resource Public Key Infrastructure (RPKI) changes that. It is a cryptographic framework layered on top of the Regional Internet Registry (RIR) system. Your RIR is AFRINIC — they hold the ground truth of which organisation was allocated which IP address block. RPKI lets AFRINIC issue signed certificates that cryptographically bind an IP prefix to the organisation that holds it. From that certificate, the organisation creates a Route Origin Authorisation (ROA) — a signed object that says, precisely:

Routers implementing RPKI validation — called Origin Validation — check every received BGP prefix against the global pool of ROAs. If the announcement matches a ROA: valid. If no ROA exists: unknown. If the announcement contradicts a ROA: invalid. Invalid routes are dropped. Unknown routes are typically accepted but treated with lower preference.

The ROA is not a secret. It sits in a publicly accessible repository that any router operator can download, cache, and query using an RPKI validator (software like Routinator, OctoRPKI, or FORT). The validator feeds route validity data into the router's BGP decision process via RTR protocol. The whole system is deterministic, auditable, and free to implement.

The Three States a Prefix Can Be In

Every BGP prefix in the global routing table exists in exactly one of three RPKI states. Understanding these states is how you read a looking glass or a BGP toolkit with intelligence rather than just curiosity.

The practical consequence: a network like Cloudflare, which implements strict RPKI enforcement, will drop any RPKI-Invalid route at their border routers automatically. They will accept Unknown routes — they have no choice, too much of the internet is still unsigned — but when they have a choice between a Valid path and an Unknown path to the same destination, policy increasingly favours Valid. TTCL's 260 prefixes all live in Unknown. Permanently second-class until they act.

TTCL's Specific Failures — AS33765

Here is what bgp.he.net and bgp.tools report, publicly, for AS33765, as of now:

This is not a small gap in coverage. This is a complete absence of RPKI participation for the oldest and largest fixed-line carrier in Tanzania — a national infrastructure provider operating a cross-border backbone into six countries. Every IP address they have ever been allocated by AFRINIC is unprotected. 77,824 IPv4 addresses. One IPv6 prefix. All of it invisible to the RPKI system.

What this means concretely: any autonomous system on the planet could, today, announce a more-specific prefix — say 41.59.4.0/24 — from any ASN and claim to be TTCL's space. Because no ROA exists to contradict that announcement, networks without strict RPKI enforcement would accept it and route toward the attacker. Traffic destined for TTCL's customers — government offices, enterprise clients, their own NOC — could be silently intercepted or blackholed before anyone realises what has happened.

This is not a theoretical attack. BGP hijacking using unprotected prefixes has disrupted YouTube, GitHub, Amazon, and dozens of major networks. The technique is documented, automated, and has been used by actors ranging from misconfigured carriers to state-level adversaries. TTCL's posture makes them trivially hijackable for any of their 259 IPv4 prefixes.

The Bogon Problem — More Embarrassing Than the RPKI Gap

A bogon is an IP address that should never appear in global routing. The term covers several categories: IANA-reserved space, unallocated address blocks, private RFC-1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), documentation ranges (192.0.2.0/24, 198.51.100.0/24), the shared address space used by carriers for CGNAT (100.64.0.0/10), and loopback/link-local ranges. None of these should ever be announced to the global BGP table. They are, by definition, addresses that cannot be legitimately routed on the public internet.

AS33765 is flagged by Hurricane Electric as announcing bogons. This is an active problem — not an absence of a record, but a presence of incorrect announcements leaving their network right now, propagating into the global routing table, and being seen by other ASNs. The reason this is more embarrassing than the RPKI gap is that fixing bogon announcements requires only an outbound BGP filter — a prefix-list that denies any prefix from the known bogon ranges, applied on every eBGP peering session. This is week-one BGP configuration. It is in every routing textbook. It is in every ISP operations training course.

In the meeting, the bogon flag is your sharpest card precisely because it is not arguable. RPKI gaps can be defended with "we're prioritising it, it's on the roadmap." Bogon announcements cannot be defended. Either you are announcing private address space to the global table or you are not. You are.

Why Their Unsigned Routes Hurt Your Network

You might read the RPKI section and think: their problem, not mine. I am not TTCL. My prefixes are separate. But the moment you connect your NNI to AS33765 and take IP transit from them, you inherit their routing environment in three specific ways.

1. Upstream filtering cascades down

TTCL's upstreams — SEACOM (AS37100), PCCW (AS3491), Hurricane Electric (AS6939) — are all progressively implementing RPKI Origin Validation. When a network like HE receives a route from TTCL for one of TTCL's prefixes, it sees Unknown and accepts it. But if TTCL ever makes a misconfiguration — announces one of your prefixes from the wrong ASN, or leaks a route into your session — there is no RPKI backstop to catch it before it propagates. RPKI is a safety net. TTCL has no net. You are transiting through a net-free environment.

2. Your traffic to RPKI-strict networks may take suboptimal paths

If a destination network has both a Valid path and an Unknown path to reach your AS, and their local policy breaks ties in favour of Valid routes, your traffic may not take the geographically shortest path. This is rare today but growing as more networks tighten RPKI policy from "prefer valid" to "require valid." Taking transit from an unsigned carrier introduces routing unpredictability you cannot control from your side of the NNI.

3. Route leaks propagate without a filter

If TTCL leaks a route they should not — either your prefix re-originated incorrectly, or a customer route they are not supposed to forward — an unsigned announcement propagates unchecked. Their upstreams cannot reject it on RPKI grounds because TTCL has no ROAs. Any misconfiguration in their BGP policy becomes your problem if it touches your prefixes or your traffic paths.

Your Own House — AS328939 and AS329647

You have been CTO of Sprint Group for one month. You did not create the routing configuration you inherited. That matters — it means the gaps below are not yours to own emotionally, but they are absolutely yours to fix professionally. A network does not care who configured it. It behaves according to its current state. Here is that state, honestly.

AS329647 (SprintTZ) has valid ROAs. This is the card you play in the room. Whoever signed those ROAs on the Tanzania side did the right thing, and you benefit from it on day one. When you pull up bgp.tools/as/329647 in the meeting and it shows ROA valid, you have standing to critique AS33765. Use it.

AS328939 (SprintUG) has zero valid ROAs — flagged identically to AS33765. This is the vulnerability TTCL's team could exploit if they are prepared, which they likely are not, but you cannot count on their lack of preparation. More importantly: you are a month into this role. The routing configuration of AS328939 is now your responsibility. Every day AS328939 runs unsigned is a day your Uganda prefix estate is as exposed as TTCL's. Five IPv4 prefixes and one IPv6 prefix that any AS could theoretically hijack without a cryptographic challenge.

How to Fix AS328939 Before the Meeting

AFRINIC's RPKI portal is at https://my.afrinic.net. You need your organisation's AFRINIC portal credentials — these would have been with whoever managed the network before you. If you cannot locate them, email hostmaster@afrinic.net with your organisation handle (ORG-SIL6-AFRINIC) and a request for access recovery. Response time is typically 24–48 hours business days.

• ✓
  Confirm AFRINIC portal access — log into my.afrinic.net with your organisation credentials. Verify you can see Sprint Internet Limited's resource page and the RPKI tab is accessible.
• →
  Identify your allocated prefixes — in the portal, under Resources, confirm every IPv4 and IPv6 prefix allocated to ORG-SIL6-AFRINIC. These are what you will create ROAs for. Do not create ROAs for prefixes you do not hold.
• →
  Create ROAs for each prefix — for each prefix, set Origin ASN to AS328939, and set Max Length to /24 for IPv4 (do not go longer — overly specific ROA max-lengths cause Invalid states for aggregated announcements). For IPv6, set appropriately to your announcement size.
• →
  Wait for propagation — ROAs published via AFRINIC propagate to the global RPKI cache network within 15–60 minutes. After that, validators like Routinator will pick them up and routers implementing Origin Validation will begin treating your prefixes as Valid.
• →
  Verify on bgp.he.net/AS328939 — after propagation, the RPKI row should show your prefixes as valid. Refresh the page. If it still shows 0, give it another hour and check again.
• →
  Audit outbound BGP policy on your MX80 — run show route advertising-protocol bgp [neighbor] on your peering sessions. Confirm only your allocated prefixes appear. Nothing from RFC-1918, nothing from 100.64/10, no summary routes beyond your actual allocations. Fix anything that does not belong.
• !
  Note on timing — if you cannot get this done before the TTCL meeting, do not raise bogon announcements or RPKI as an attack angle. Use it only as the mutual-upgrade proposal framing: "both of us have work to do, let's commit to a timeline together." That is still a strong position — it just avoids the hypocrisy exposure.

How to Use All of This In the Room

You do not lead with RPKI. You do not walk in and say "your AS has zero valid routes." That is an attack, and attacks make people defensive. Defensive people stall commercial negotiations. You are there to close a partnership, not to embarrass their engineering team in front of their management.

You lead with what you want: the APN architecture, the backhaul PoPs, the IP transit path to Uganda. You establish that you are technically serious — you know what PDN-GW means, you know what AS path prepending does, you know what CIR means. You let the conversation settle.

Then, when the conversation reaches technical trust and routing quality — and if you ask the right questions about BGP communities and RPKI filtering, it will get there — you open the looking glass.

You say: "Before we talk about what routing guarantees we need from this agreement, let me show you where both of us are today." You open bgp.he.net/AS329647 first. ROA valid. Clean. Then you open bgp.he.net/AS33765. Zero valid. Bogon flag. Let that sit for three seconds of silence. Then you open bgp.he.net/AS328939 yourself, before they can. Zero valid. You say: "We are working on Uganda. It is on my 30-day list. I own that. What I want to propose is that we both commit, in this agreement, to a mutual routing hygiene milestone. AS329647 is already there. We sign AS328939 within 30 days. You commit to signing AS33765 ROAs within 90 days."

That is not a negotiation. That is an engineering leader setting a standard. You have just made TTCL's RPKI gap their deliverable in your partnership agreement. The commercial team across the table will not fully understand what they are agreeing to. The engineering team — if there is one in the room — will be quietly embarrassed and relieved that someone finally put it on paper.

You have been running networks longer than some of those engineers have been drawing salaries. You rebuilt an MX80 from U-Boot. You know what J1939 CAN bus looks like from the inside. The routing table is just another protocol stack — deterministic, honest, and utterly unimpressed by titles. Read the table correctly and the room follows. That is the only qualification that matters in a room like this.

AS328939 · AS329647 · AS33765 · codeandcore · April 2026