[db-wg] Missing org: fields for direct allocations from RIPE

Ronald

This is more of an Address Policy issue than Database. But as you have
raised it here, I will respond. You suggested that "I" told you to
shut up and go away. If you have ever felt anything I have said gave
you that impression I apologise. In fact for years I have been trying
to do the opposite. I want more people involved in discussions about
internet operations and decision making.

So legacy space. I am sure addressing experts will correct me if I am
wrong. As I understand it, the 'owners' of legacy space have 3
options. They can convert it to ALLOCATED PA and it becomes RIPE NCC
allocated space. Or they can have a contract with the RIPE NCC to get
some benefits but it remains legacy space and their property. Or they
can just document it's existence in the RIPE Database and remain
completely anonymous. In this latter case they don't have to identify
themselves, follow any RIPE policies or procedures or link the address
space to any organisation. They just exist in the shadows. I didn't
realise this latter case still existed to the extent it does. I was
told recently that there is still a lot of legacy address space in the
RIPE Database that the RIPE NCC has no idea who is accountable for it
and has no means of contacting anyone in relation to it.

Now personally I totally agree with you. I think it is crazy to have
address space documented in the RIPE Database that is owned by
unidentified and unaccountable people. When writing policy proposals
we have to be clear that it will only apply to legacy space that is
subject to a contract with the RIPE NCC. We can't impose policies on
this unaccountable space. A lot of this legacy space is owned by
honest people and used responsibly, but for some reason they still
wish to remain anonymous. It makes no sense to me at all. Every IP
address is identical to every other IP address in terms of how it is
used. There should be no difference in how it is accounted for. I
don't care how they own it or by what contract terms. If it is used
for a public network then the public should have the same information
about who is using it. I have been told many times that even if the
RIPE community was to approve a policy requiring all legacy space to
be fully documented and accountable for in the RIPE Database, there is
no legal means to enforce such a policy.

cheers
denis
co-chair DB-WG

On Fri, 29 Apr 2022 at 00:50, Ronald F. Guilmette via db-wg
<db-wg at ripe.net> wrote:
>
> Some considerable time ago I previously noted here the fact that there
> exists in the RIPE WHOIS data base some WHOIS records for what I personally
> would refer to as "top level" IP address block allocations (i.e. ones which
> were assinged directly by RIPE NCC to some specific RIPE member organization)
> and that contain no org: field which would otherwise associate these blocks
> with a specific organisation having its own organisation: record in the
> data base.
>
> At that time, I was basically told (by denis, as I recall) that this was
> a historical artifact in the data base, that it would absolutely NOT be
> rectified, and that I should go pound sand.
>
> Having long ago become resigned to this level of respectful helpfulness
> when raising legitimate issues relevant to the RIPE data base here, I
> let it go, and I have not raised the issue again since that itme.  Now
> however I feel that I have some clear and concrete basis for doing so.
>
> I call everyone's attention to the following post that I just made to
> the mailing list of the RIPE Anti-Abuse Working Group:
>
> https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2022-April/006346.html
>
> I should say that it is my (naive?) belief that (a) every operator of
> an inbound mailbox or an inbound mail server should have the right to
> decide for themselves when any given network is not worthy of having
> its inbound emails accepted, and also (b) RIPE and the RIPE WHOIS
> data base should not make the task of locally filtering inbound packets
> or emails from a given network any harder than it needs to be.
>
> As noted in the mailing list post linked to above, it is my desire to
> locally block all further inbound emails from the entire set of IPv4 CIDRs
> currently associated with the Dutch network which is alternatively known
> as Signet B.V. and/or TransIP B.V.  (These people are clearly lack the
> requsite minimal level of competence to run a network from which outbound
> emails emmanate.)
>
> In any universe guided by either reason or simplicity it should be easily
> possible to find the ORG handle for any given (offending) network and then
> to use that handle as a "reverse" lookup key in a query to the relevant
> RIR data base and thus automatically derive the full set of IP address
> blocks currently assigned to the given organization.  Unfortunately, and
> for reasons that have yet to be adequately explained, we do not live in
> that simple or rational universe, at least not when it comes to the RIPE
> WHOIS data base.
>
> For quite some time now I have had a relatively trivial Perl script that
> does this exact job.  I call it "org2cidrs".  It works flawlessly when
> provided an ORG handle known to any one of the five Regional Internet
> Registries, except in the case of RIPE where, as I have noted above, some
> IP block allocations have no org: field and thus no connection to any
> particular organisation... at least none that could be automatically
> determined by a reverse WHOIS query based on some ORG handle.
>
> The bottom line is that although I have found it quite easy to deduce
> that the handle ORG-SI6-RIPE represents the offending organization that
> I would now like to block, a reverse (org) WHOIS query against the RIPE
> WHOIS server using that handle yields only a subset of the IP block
> allocations currently assigned to that organisation.  More specifically,
> although the vast majority of IP blocks assigned to this organization do
> in fact have corresponding WHOIS records in the data base that -do-
> contain an org: field designating ORG-SI6-RIPE as the registrant
> organization, the following two blocks, both marked as "status: LEGACY",
> have no org: field present in their respective RIPE WHOIS records, and
> thus these allocation records are effectively invisible to any reverse
> WHOIS query using -any- ORG handle  (e.g. ORG-SI6-RIPE) as lookup key:
>
> 136.144.128.0/17
> 157.97.168.0/22
>
> I don't know how to say this delicately, so I will just say it.  It is,
> in my opinion, fundamentally idiotic that every other one of the five
> Regional Internet Registries make it trivially easy to find ALL of the
> IP allocations associated with a given ORG handle, but that RIPE, for
> reasons that are apparently shrouded in mystery and/or which have long
> ago been lost to the sands of time, continues to insist on making what
> should be simple difficult.
>
> The last time I checked there were only on the order of about 122 "top level"
> RIPE IP block allocations whose corresponding WHOIS records failed to
> include an org: field.  In each of these cases it would be trivially possible
> for RIPE NCC to manufacture an appropriate organization: record out of the
> information already in the data bases and/or information which is readily
> available on the web or from the actual organizations themselves.  Once
> these new organisation: records were created it would also be trivial for
> RIPE NCC to insure that every single IP block allocation in the data base
> is associated with some ORG handle, thus simplifying automated processing
> of the data base -and- bringing its functionality into line with that of the
> other four RIR data bases.
>
> The fact that this has not already been done, especially in a case like the
> legacy blocks which clearly belong to ORG-SI6-RIPE, is, I think, indicative
> of some narrow-minded insistance on the preservation of past practices,
> even when those practices are, as in this case, provably detrimental to
> reasonable and serious users of the data base.
>
>
> Regards,
> rfg
>
>
> P.S. I have always and will always argue in favor of anything that simplifies
> the parsing and/or automated processing of WHOIS data base records.  Having
> *every* IP block allocation record include an org: field would do just that.
>
> Furthermore, quite frankly I am both flummoxed and flabberghasted that a
> call was made here, some time ago, for suggestions on how to make it simpler
> to parse the data base, EVEN AS my simple, straightforward, and (I would have
> thought) obvious suggestion to represent all handles in the data base only
> and consistantly in upper case garnered -no- response from this working
> group whatsoever.
>
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/