Hello ZANOG.
(Please excuse me if this message has been duplicated.)
My name is Tijay Chung, and I am a researcher at Virginia Tech.
Our team at Virginia Tech has been building
ASINT, a research tool that
maps ASNs to their operating organizations by combining Internet-routing metadata (WHOIS, PeeringDB, corp websites, M&A records, etc.) with large-language-model analysis. It is conceptually similar to CAIDA's AS2ORG, but with broader coverage. A use case is reducing false positives in BGP hijack detection by identifying when different origin ASNs actually belong to the same organization.
Please try it:- AS search for AS 18733 (Microsoft and acquired ASNs): https://asint.netsecurelab.org/as-search/18733
- Organization search for Deloitte (across multiple RIRs):
https://asint.netsecurelab.org/org-search?q=deloitte
Why this might help:Systems like Cloudflare Radar flag anomalies when the origin ASN does not match ROAs. Many of these are not hijacks but legitimate internal re-announcements between sibling ASNs. In our dataset of 17,282 such alerts (Jan 2023–Jul 2024), ASINT identified 1,621 cases (~9.4%) as likely intra-org. We sampled 100 of these and contacted operators; all 32 who replied confirmed they were internal, not hijacks.
What we need from you:
1. Please check your org and ASNs. If you see a correct mapping, click the thumbs-up. If you see an error or a missing ASN, click the thumbs-down. After that, a short comment box appears. Any details you can share are valuable: correct legal entity name, subsidiaries, brand vs legal names, recent M&A, reseller or DDoS-scrubbing scenarios, multi-tenant NOCs, government or university structures, region-specific business units, joint ventures, or anything else that explains why two ASNs should or should not be grouped.
2. Expect errors. We know there are two classes:
- False positives: we group ASNs under the same organization even though they are different.
- Misses: we fail to group sibling ASNs that should be together.
If you spot either, please rate and leave a comment. We will feed your comments into the next LLM pipeline cycle to correct mappings and tune extraction rules.
3. Any feedback is welcome: data sources we should incorporate, edge cases that keep biting you, risk of over-merges vs under-merges, UI issues, or better ways to present evidence. If you prefer email, reply here or write to our team:
tijay@vt.edu,
yongzhe@vt.edu,
weitongli@vt.edu
We aim to complement, not replace, existing datasets and community curation. If you maintain ground-truth lists for your org and are willing to share pointers, that helps everyone.
If this is useful, we will report a summary of corrections learned from the community and continue iterating.
Thanks for taking a look and for any time you can spare.