Re: incorporation state of ARIN's asn.txt / LACNIC AS name data

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3758 bytes --]

Hello nusenu,

> On 27 Jun 2021, at 11:14, nusenu <nusenu-lists(a)riseup.net> wrote:
> 
> Hi Peter,
> 
> thanks for your comprehensive reply.
> 
> Peter Müller wrote:
>> the AS names file provided by ARIN does not contain human-readable AS
>> names (although DigitalOcean is one of the better examples in
>> there), I rather see it as an improvement than a solution. :-)
> 
> out of curiosity: I haven't understood your differentiation between "human-readable" and "technical" AS names.
> Would you mind elaborating on your definitions of human-readable AS names?
> 
> I understand AS name as the name attribute of the AutNum WHOIS object.
> 
> to use an example again:
> "DIGITALOCEAN-ASN" is the AS name of AS14061 according to [1], WHOIS [2] and well
> established tools like RIPEstat show the very same string [3].
> 
> [1] https://ftp.arin.net/info/asn.txt
> [2] https://whois.arin.net/rest/asn/AS14061
> [3] https://stat.ripe.net/widget/as-overview#w.resource=AS14061
> 
>> If you or anybody else has any idea of getting more precise location
>> or AS data for space maintained by these two RIRs in a reliable way,
>> we will be most interested in hearing about it.
> 
> with regards to LACNIC: Maybe their bulk whois data is something you
> find useful? (I didn't use it myself)
> 
> https://www.lacnic.net/en/web/lacnic/manual-8
> https://github.com/microsoft/WhoisParsers/blob/fb54e3cf576e5caa4d2f8e0c15768925d14dc464/WhoisDownload/WhoisDownload.cs#L45
> 
> RIPEstat is also an option for AS names but it is not bulk data and
> requires one request per ASN to get the well formated JSON response.
> 
> 
>> The reason why you do not see those AS names in production is
>> because there is no new libloc release, yet. There is one bug
>> (#12553) left to fix, but afterwards, I guess we are fine to release
>> libloc 0.9.7; a day later, the generated database dump should contain
>> the AS information.
> 
> Do you have a rough estimate on when this next version will be released?
> 
> 
>> For the sake of completeness, I take the liberty to note that the
>> database.txt file you are referring to, and the Tor maintainers
>> retrieve for baking it into their releases is _not_ the actual
>> location database. So, technically, Tor is using the data
>> conglomerated together by libloc - which we are happy about -, but
>> not libloc itself. As far as I am aware, they decided against
>> shipping libloc with Tor for the moment, primarily due to
>> compatibility issues with the 0.3.5.x LTS branch.
> 
> I'm aware of the differences here. To be precise I'm not referring to the
> db file that the torproject ships with tor releases.
> I'm referring to their onionoo service (https://metrics.torproject.org/onionoo.html)
> which uses ipfire's db as data source as well since recently.

I just wanted to add something (potentially rather obvious here):

We originally designed this project with the library which is where probably the biggest value is. It comes with many features like:

* Super fast lookup of any data because we store it in a quite smart way.
* A simple C API so it can be integrated into many projects (and we have bindings for Python 3 and Perl, too).
* One of the most important ones: It cryptographically verifies the database when it is being updated. That way, it can be trusted as it not being downloaded from a random HTTP server.

As far as I can see (couldn’t find any up to date source code) onionoo is written in Java. Is that an obstacle and are there any blockers why libloc cannot be used apart from that there are no bindings for Java available?

Best,
-Michael

> kind regards,
> nusenu
> 
> 
> 
> -- 
> https://nusenu.github.io