Summary

  • A stale RADB aut-num object for AS27525 still reads "added for Gafachi, INC by Net ACCESS", but ARIN reassigned that autonomous system to Fidelity National Financial Inc. on 2018-10-03, and Hurricane Electric reports AS27525 has not been visible in the global routing table since November 21, 2017.
  • Gafachi's current registry footprint is AS40105 (ASNAME-PRV-GAF-1), registered 2025-11-03 for the joint use of PriVerify Corp. and Gafachi Telecom USA LLC, announcing exactly one IPv4 prefix, 23.149.20.0/24, with zero RPKI-valid coverage in third-party sampling.
  • No documented BGP route leak or hijack was located for any Gafachi-linked ASN in this investigation; Qrator Radar's dashboard for AS40105 surfaces zero accepted leaks and zero hijacks.
  • The accountability question is therefore not an incident record but a control-surface one: registry identity is fragmenting, routing-security controls are not verifiable, and the company's own security branding is not matched by any published routing-security posture.

A registry record that outlived its owner

Start with the oldest artifact. In the RADB — one of several internet routing registries that operators consult when building filters — the aut-num object for AS27525 still reads:

aut-num: AS27525 as-name: GAFAC descr: added for Gafachi, INC by Net ACCESS member-of: AS-GAFACHI import: from AS8001 accept ANY export: to AS8001 announce AS-GAFACHI

The object's changed field dates to 2008-12-17 and its last-modified timestamp is 2023-11-13, according to a third-party aggregator (Robtex) and the mirrored RADB data visible on Hurricane Electric's ASN page (bgp.he.net/AS27525). In plain terms: as late as November 2023, the routing-registry record still attributed this autonomous system to Gafachi, Inc., more than a decade after the object was first maintained.

The problem is that ARIN disagrees. The authoritative American registry's data for the same number shows ASName FNF-CLOUD2, registered to Fidelity National Financial Inc. of Jacksonville, Florida, with a RegDate of 2018-10-03, as reproduced in registry-derived mirrors (whois.ipip.net/AS27525). A historic CIDR Report table separately catalogued the same ASN as "GAFACHI-AS - Gafachi, Inc." (cidr-report.org), which confirms that the number was once publicly associated with Gafachi in aggregation data — and that today's ARIN owner is a different company.

There is a further wrinkle. Hurricane Electric's page for AS27525 states that the ASN "has not been visible in the global routing table since November 21, 2017" and notes that some displayed information is from that time (bgp.he.net/AS27525). So the stale Gafachi object describes a system that has, in routing terms, been dark for years. Nobody is being harmed by the GAFAC record right now in any documented way. But the record exists, it still names a company, and it conflicts with the authoritative registry — a textbook case of registry identity drift.

One correction belongs in any honest account, because the research path here started with a false lead. AS395831, sometimes surfaced in connection with routing-security queries, belongs to Meraki LLC (Cisco Meraki) of San Francisco, registered 2017-04-27, and has no Gafachi nexus (bgp.he.net/AS395831). That attribution is unsupported and is excluded from the findings that follow.

The current footprint: AS40105 and the PriVerify joint use

Gafachi's live registry presence today is smaller and stranger than its history. ARIN data for AS40105 (ASNAME-PRV-GAF-1) describes it as "PriVerify Corp. and Gafachi Telecom USA LLC joint use. Used at multiple POPs in the United States", with a RegDate of 2025-11-03 and operational contacts under the handle RNOPL-ARIN — "Routing and Network Operations PRV Layer 3" (bgp.he.net/AS40105). PriVerify Corp., the ARIN organization record shows, is based in Lockport, New York.

The joint-use framing is formalized further in an ARIN IRR route-set, RS-PRV-GAF-US-1, created on 2025-12-11 under maintainer MNT-PC-2225. Its description reads "PriVerify Corp. and Gafachi Telecom USA LLC joint use. Used at multiple POPs in the United States"; it lists member 23.149.20.0/24 and an IPv6 mp-member, 2604:2760::/32 (bgp.he.net/irr/route-set/RS-PRV-GAF-US-1).

What does this system actually announce? Precisely one IPv4 prefix. Hurricane Electric reports one originated prefix — 23.149.20.0/24, 256 addresses — and zero RPKI-originated-valid prefixes across all address families, with one observed peer and 650 observed IPv4 AS paths (bgp.he.net/AS40105). IPTrace independently reports the same shape: one announced IPv4 prefix, "RPKI Valid 0 / RPKI Invalid 0 / Unsigned or Unknown 1", sampled 1 of 1 — a 0% RPKI valid rate for the prefix the system originates (iptrace.net/en/as/40105).

That gap matters. RPKI origin validation is the routing-security control that lets other networks verify, cryptographically, that an autonomous system is authorized to announce a prefix. A network that originates a prefix with no ROA coverage is not necessarily doing anything wrong — plenty of small operators have not adopted RPKI — but the absence means that anyone relying on the announcement has no cryptographic assurance, and that the operators themselves have left one of the cheapest, most standardized controls unused.

Registry intent also exceeds observed behavior: the IPv6 block 2604:2760::/32 is registered in the route-set but does not appear among the prefixes AS40105 is observed originating, so the record describes capability the routing table does not yet reflect.

What independent monitors say about incidents

An accountability investigation has to be careful about the negative finding, because "no incident found" is not the same as "verified clean". Here is what the third-party evidence shows.

Qrator Radar, a BGP monitoring service, surfaces counters for AS40105 showing zero accepted route leaks and zero hijacks in its view, alongside RPKI ROA panels (radar.qrator.net/as/40105). This run's search of routing-registry aggregators, monitoring dashboards and operator sources located no documented BGP route leak or hijack attributed to any Gafachi-linked autonomous system — AS27525 or AS40105. The negative finding is stated as an absence of located evidence, not as an audited clean record. Qrator's counters are dashboard values whose observation dates are not fully legible from the excerpts available, and the RPKI panel readings there are not straightforwardly reconcilable with IPTrace's zero-valid sampling; both are point-in-time samples from third parties.

The framework for why this matters comes from the wider routing-security literature, not from Gafachi. Route leaks and hijacks are classified under RFC 7908, and modern remediation toolkits combine RPKI origin validation, RFC 9234 BGP roles, ASPA, IRR-based filtering and CI/CD checks on routing policy — a stack documented by operators who have published incident post-mortems, as documented in operator-published post-mortems of recent major route leaks and hijacks.

Against that yardstick, the observable facts for Gafachi's joint ASN are: one prefix, no ROA, no published filtering policy, no MANRS participation located, and no published security posture of any kind.

Who Gafachi is: the Rochester documentary record

The corporate anchors are older and more solid than the routing records. A letter dated February 9, 2005, filed with the New York State Public Service Commission, concerns the interconnection agreement between Frontier Telephone of Rochester, Inc. and Gafachi Telecom-NY, Inc., and lists Gafachi's representative as Adam Glynn at 1 West Main Street, Suite 650, Rochester, NY 14614 (NY Department of Public Service filing). This is a regulator-filed document: Gafachi operated in Rochester at least two decades ago, and Adam Glynn has represented it since 2005.

Company-profile material describes Gafachi as a Rochester-headquartered facilities-based wholesale VoIP carrier founded in 2001, licensed as a CLEC/IXC in New York and California, with an additional Lockport office (exa.ai organization profile). PeeringDB — self-reported organizational data — lists a Gafachi facility at 1 West Main St, Rochester, NY 14614, with the company website gafachi.com and a last update of 2025-09-26 (PeeringDB facility record). The same address recurs across twenty years, which is a rare continuity signal for a small operator.

The PriVerify link has its own paper trail. On October 24, 2017, Adam Glynn — identified in the post as PriVerify's President and Head of Engineering — published a LinkedIn post describing PriVerify as a "Gafachi-affiliated security firm" investing in partnerships, including co-op programs with Rochester Institute of Technology, and advertising proprietary security incident simulation software (LinkedIn post). This is self-published promotional content, and the affiliation it claims is not independently audited anywhere this run located — but it is corroborated, structurally, by the 2025 ARIN artifacts: the route-set and the ASN registration both formally name the PriVerify Corp./Gafachi Telecom USA LLC joint use.

So the picture is coherent: a real Rochester-area company with a twenty-year footprint in voice interconnection and wholesale services, an affiliated security-marketing entity, and a new, minimal joint autonomous system registered in late 2025. What is missing is everything a reader would want to see on the security side: no RPKI coverage for the prefix it announces, no published filtering policy, no MANRS status, and no public statement about routing-security controls from either entity.

What should be verified

Three questions follow from the evidence, and none of them is an accusation — they are the concrete items an operator, a peer, or a customer of this network could verify or ask about.

First, who controls routing policy for AS40105, and does any RPKI ROA exist for 23.149.20.0/24 now? The third-party samplings consulted showed zero valid coverage at their observation time; a current check would settle whether the gap persists.

Second, will the stale GAFAC RADB object for AS27525 ever be cleaned up, and who maintains it? The object names Gafachi under maintainer MAINT-AS8001 (Net Access); the ARIN holder is Fidelity National Financial. Registry hygiene of this kind is normally the maintainer's job, and a 2023 last-modified date on a record for a system that has been dark since 2017 suggests nobody has bothered.

Third, does PriVerify's advertised security focus translate into any published routing-security practice for the joint ASN — MANRS participation, documented filtering, RPKI deployment? Nothing located in this investigation answers that; the question is open.

The delta over BTW's prior coverage is specific: the only earlier BTW article on Gafachi (published 2026-06-14) treated the company exclusively as an ARIN registration watchpoint whose dormancy could signal resource reclamation or transfer. It contains no ASN analysis, no routing-security investigation and no registry-conflict finding. What this account adds is the fragmenting identity across two autonomous systems, the unverified control surface of the new joint ASN, and the located absence of any incident record — facts that change what a reader should watch, and how.