From: "Peter Müller" <peter.mueller@ipfire.org>
To: location@lists.ipfire.org
Subject: Re: [db-wg] Question regarding delta between "delegated-ripencc-extended-latest" and Whois output
Date: Mon, 29 Jun 2020 19:54:15 +0000 [thread overview]
Message-ID: <7793c0df-00e8-315d-20a5-24cacb76837a@ipfire.org> (raw)
In-Reply-To: <e4edd768-562a-6475-e34f-26e512d0a999@foobar.org>
[-- Attachment #1: Type: text/plain, Size: 3549 bytes --]
Hello Nick, hello Leo,
thanks for your fast and informative replies. I take the liberty to reply to
both of you at the same time.
> The RIPE Database, queried by Whois or RDAP, serves a different
> purpose from the stats file. The former enables communication between
> operators and supports the routing registry. The latter is to provide
> high level statistical data to researchers.
I see, it did not became clear to us that those file mainly exists for
statistical purposes - we were glad to find something that has a unique
syntax across all RIRs, instead of reintroducing the wheel for each one.
Oh well... :-)
> Incidentally, IP address allocation queries in the RIPE Database now
> return the country where the holder of the block is legally resident,
> not where the IP address is actually used.
Yes. This seems to be a common source of misunderstandings when trying to
assign a country code to an IP network, as most people/applications/databases
do not specify if they are trying to show the jurisdiction of that IP
network, or the country where its machines are physically located. In
my humble opinion, the latter is hard - if any - to determine.
> The situation with 51.15.0.0/17 and 51.15.0.0/16 is only the tip of a
> gigantic iceberg of quirks and anomalies, not just because you have
> inconsistent statements about the country, but also because this is
> legacy (i.e. pre-RIPE) address space and there can be multiple inetnum
> entries in the ripedb which may be fully inconsistent with each other and
> where all, some or none of the inetnum records may be an accurate reflection
> of reality.
Although we have already sensed something in that direction, it is a
bit frustrating to receive that message from someone in the RIPE DB working
group...
What would you do if you need to build a database to determine the
country assigned to an IP address - let's take the one assigned to it by
it's owner, regardless of jurisdiction or physical location -? Would you
collect the most specific inetnums first, and proceed with the less specific
ones?
(Basically, this is what we trying to do as we need to replace the GeoIP
database provided by MaxMind due to license changes - some other open-source
projects are in need of an alternative as well -, and instead of just using
the next commercial provider, we are trying to build an open-source solution.
In case of further interest, please refer to:
https://blog.ipfire.org/post/on-retiring-the-maxmind-geoip-database)
> I.e. if you're planning to use either the RIPE DB or any other whois db
> for the ipfire geoip blocking mechanism, you may want to consider putting
> up very large and obtrusive warnings about how thoroughly inaccurate
> geoblocking may end up being in practice.
I believe we are more or less aware of that inaccuracies. Personally, I consider
firewall rules based on Autonomous Systems Numbers to be _way_ more precise
and practical - countries like US or NL are hard to block in productive environments.
We are keen to raise awareness of those issues in our user community as
well, but unfortunately are unable to drop the ability of selecting countries
as source or destination of a firewall rule completely. For a quick look, it
also might be interesting to show some geographical information so very
unusual connections are easier to identify.
Anyway: Thanks for your replies so far and thanks in advance for the upcoming ones. :-)
Thanks, and best regards,
Peter Müller
next prev parent reply other threads:[~2020-06-29 19:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-29 17:30 Peter Müller
2020-06-29 19:07 ` [db-wg] " Nick Hilliard
2020-06-29 19:54 ` Peter Müller [this message]
2020-06-29 20:21 ` Nick Hilliard
2020-06-29 20:52 ` Leo Vegoda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7793c0df-00e8-315d-20a5-24cacb76837a@ipfire.org \
--to=peter.mueller@ipfire.org \
--cc=location@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox