Hi guys Historical queries to the RIPE Database only go back as far as the 'most recent' creation. So you can see changes made to the currently existing INETNUM object. If the object has been deleted and re-created it is not possible to query for the previous incarnation of the object. This was an arbitrary decision made when the historical query feature was introduced. The data is still available in the RIPE Database for all previous incarnations of an object. It has been suggested in the past that this service be extended to show all previous history (excluding personal data). If there is sufficient interest, maybe someone would like to propose such a change and it can be looked into in more detail. cheersdenis co-chair DB-WG On Tuesday, 10 December 2019, 13:16:08 CET, Roland Perry <roland@internetpolicyagency.com> wrote: In message <20191210114312.GJ72330@Space.Net>, at 12:43:12 on Tue, 10 Dec 2019, Gert Doering <gert@space.net> writes

Hi,

On Mon, Dec 09, 2019 at 05:47:26PM +0000, Roland Perry wrote:

...

My question is this: how can the organisations responsible for that former life be identified (in general terms) so that the end users can at least given a plausible explanation for why their connectivity has been so badly affected.

As far as I know, all the new ISP is prepared to divulge is "we are working on it", and all the users' IT departments are prepared to divulge is "Our new ISP says he's working on it".

If this is ISP-managed space ("provider aggregateable", PA, in RIPE lingo) this is a matter between the end customer and their ISP.

If(!) the ISP has been well-behaving RIPE member and documenting their assignments in the RIPE DB, the historic snapshots of the inetnum records will shed light.

How do I as (nowadays anyway, an outsider) access such historic snapshots of the IP address range, before today's ISP acquired them. Is this a 'service' that RIPE NCC offers (and hence my question in this forum). Sometimes the answer is "we aren't allowed to tell you - because of data protection". But I suspect the dirt was acquired by a user outside the EU, and hence arguably outside the protection of EU DP law.

But I see this as somewhat unlikely, as it seems the ISP is unwilling to fix up the mess they created for their new customer.

I'd just send laywers their way - "you gave us these addresses, they are close to unusable, go fix things or give us clean ones, or we'll change ISPs again and you pay for all costs incurred"...

If I were the admins in this case, I would have (weeks ago) demanded "some new clean ones", seeing as how the process of cleaning the current ones is proving less than adequate. But unfortunately the customer organisation is part of a consortium, and you'd need to get a lot of *other* members on side. Being able to say who attracted the dirt, is my motivation for assisting in an attempt to get a critical mass of consortium members to act. -- Roland Perry

Hi Roland,

Thus, if law enforcement turned up and asked "about this /22 IP range, which we know has been in the hands of a beleaguered UK ISP the previous few months, but who was responsible for it, say, a year ago", you'd say "it's in the database, but you can't access it, because we don't have a query for it"?

I have a tool that is going back into 2013 with snapshots of the RIPE DB information for each other day (somewhat) ... that provides details about the registrant of the IP space and if it was in BGP at the time. If you have 1 specific question (prefix) I would be more than willing to see if I can assist you . . . If this is going to be a duck hunt .. I would have to see if we want to go there. Let me know if needed, Erik Bais On 10/12/2019, 15:55, "ncc-services-wg on behalf of Roland Perry" <ncc-services-wg-bounces@ripe.net on behalf of roland@internetpolicyagency.com> wrote: In message <1689008734.428292.1575985321858@mail.yahoo.com>, at 13:42:01 on Tue, 10 Dec 2019, "ripedenis@yahoo.co.uk" <ripedenis@yahoo.co.uk> writes >Hi guys > >Historical queries to the RIPE Database only go back as far as the >'most recent' creation. So you can see changes made to the currently >existing INETNUM object. If the object has been deleted and re-created >it is not possible to query for the previous incarnation of the object. >This was an arbitrary decision made when the historical query feature >was introduced. The data is still available in the RIPE Database for >all previous incarnations of an object. > >It has been suggested in the past that this service be extended to show >all previous history (excluding personal data). If there is sufficient >interest, maybe someone would like to propose such a change and it can >be looked into in more detail. Thus, if law enforcement turned up and asked "about this /22 IP range, which we know has been in the hands of a beleaguered UK ISP the previous few months, but who was responsible for it, say, a year ago", you'd say "it's in the database, but you can't access it, because we don't have a query for it"? -- Roland Perry

On 10 Dec 2019, at 13:15, Roland Perry wrote:

… How do I as (nowadays anyway, an outsider) access such historic snapshots of the IP address range, before today's ISP acquired them.

Is this a 'service' that RIPE NCC offers (and hence my question in this forum). …

https://stat.ripe.net/ Type in the prefix concerned. The ‘Anti-abuse’ tab lists some well known blacklists, also historically. The ‘ Database’ tab has registration and allocation history. The ‘Routing’ tab has routing history. In my experience all this goes a long way to get a good picture of the address space concerned. It would be helpful if you told the list whether this would have warned this particular end-user had they or their consultants looked at it. Daniel

On 10 Dec 2019, at 16:58, Roland Perry wrote:

In message <6C247001-B2CB-4CFD-818B-E31EC48D9134@ripe.net>, at 16:01:41 on Tue, 10 Dec 2019, Daniel Karrenberg <dfk@ripe.net> writes

...

On 10 Dec 2019, at 13:15, Roland Perry wrote:

...

… How do I as (nowadays anyway, an outsider) access such historic snapshots of the IP address range, before today's ISP acquired them.

Is this a 'service' that RIPE NCC offers (and hence my question in this forum). …

https://stat.ripe.net/

Type in the prefix concerned.

Thanks, Daniel. As ever you are a star!

The stars are the engineers who make RIPEstat work. I was just the initial instigator to set this up.

...

The ‘Anti-abuse’ tab lists some well known blacklists, also historically.

But shows nothing. (Nor had my earlier searches elsewhere)

We cannot possibly cover all blacklists. It is just an indication. We may add more public blacklists on suggestion.

The block that a friend encountered yesterday, and made me decide to look into this further, was from Hootsuite, which is a social media management platform.

Ones that had been previously mentioned by other users include Adobe, PayPal and Eventbrite.

Those usually do not publish their prejudices …. :-(

...

The ‘ Database’ tab has registration and allocation history.

Which suggests an allocation to the ISP in July 2015...

That’s what I read into that. So I guess the customer should complain to the ISP.

...

The ‘Routing’ tab has routing history.

...and to customers in 11th March 2019. Which together *doesn't* match a theory of either recent acquisition, nor a hangover from dirty usage.

I read the same.

...

In my experience all this goes a long way to get a good picture of the address space concerned.

It would be helpful if you told the list whether this would have warned this particular end-user had they or their consultants looked at it.

Nothing leaps out at me.

Not really in this case.

Which leaves the question of where the data being acted on by the undoubtedly active block lists originated. But could explain why it's apparently difficult to expunge, if it's of unknown source.

The name 'Globalprotect' was also mentioned.

My next theory is that it's not a poorly sanitised transfer of IP addresses, but some glitch in the blacklisting process.

That’s what I would go with. I have heard similar stories. If you are inclined towards conspiracies it may also be deliberate poisoning. I have seen evidence of this in the past. Also some of this may be based on goofy geolocation. My family server for instance suddenly seems to be regarded by some as somewhere in Russia even though it has not moved from Germany in years. This way I can practise my hardly existent Russian by trying to decipher the google ads. ;-) Daniel

In message <0FBE48E1-5DA1-4D1B-B973-B3538AFD45B0@ripe.net>, at 14:41:37 on Wed, 11 Dec 2019, Daniel Karrenberg <dfk@ripe.net> writes

Also some of this may be based on goofy geolocation. My family server for instance suddenly seems to be regarded by some as somewhere in Russia even though it has not moved from Germany in years. This way I can practise my hardly existent Russian by trying to decipher the google ads. ;-)

This is becoming ever more likely as the cause (of the grief to the ISP's customers). Because I've now found anti-abuse sites which allege that the UK-based ISP who received this block of addresses in March 2019, is located in the somewhat distant country from which the addresses were transferred. Flush the cache, someone! There is no need to disclose (or receive) any personal information regarding the individuals involved in this chain of events, to identify potential corporations who need persuading to correct this erroneous statement of affairs. Mindful that one of the original Data Protection Principles was a commitment to an ethic of: "accurate and, where necessary, kept up to date". -- Roland Perry

On 18 Dec 2019, at 09:51, Daniel Karrenberg <dfk@ripe.net> wrote:

current policy is to not make it available because of privacy concerns. Unless there is pressure from the community that is not likely to change soon. I am no lawyer but I expect that this policy could change at least for data that is not ‘personal data’, which would be good enough for what you seek. But I guess that more than two people have to ask for it. A reasonably concise request from this WG would go a long way.

IMO it would be wiser to do this via the PDP. Doing this via some other route is a recipe for confusion and inconsistency. It doesn’t seem right to change/tweak existing policy on the fly either. That said, I see the value in making historical resource holder data available and support that principle.

Hi Daniel,

Apologies for using the word policy without proper qualification. ;-) As far as I know this is a RIPE NCC internal policy and not a RIPE policy. At least I could not quickly find a RIPE policy to this effect.

I think you are correct. But I agree with Jim that we should decide such a change by consensus and make it a RIPE policy. That will also help the RIPE NCC if anybody every challenges them on publishing that historical data. Cheers, Sander

On 18 Dec 2019, at 11:06, Daniel Karrenberg <dfk@ripe.net> wrote:

Any volunteers to write the policy proposal?

I suspect Sander and myself have just been volunteered. :-)

There is a task force …

I hope we don’t need a task force to write a policy proposal.

Hi Guys Just to add a bit of context. Historical queries currently show the history of a resource object back to the most recent creation date. So if an object is created, modified several times, deleted, re-created, modified several times all you can query is the modification history back to that re-creation point. There is no community policy regarding this. It was an arbitrary decision made (probably by me at the time) when we specified the historical query feature a few years ago. We were asked for this feature but there were no requirements other than 'please show us some history'. From an implementation point of view this was the 'low hanging fruit' to get a feature developed in a reasonable amount of time. The full history of resource objects going back decades is still available in the database. Roll the clock forward and GDPR kicks in. It seems now that much of the data IS considered to be 'personal'. Even nic-hdls are considered to be personal data as they can be used to identify an individual. Also there is the issue of the reuse of nic-hdls for many years. So a nic-hdl from a resource object that existed say in 2008 may exist in the database today but it may be a different person. There is also the issue that the database has never differentiated between personal and corporate data. PERSON and ROLE objects are interchangeable and can be used in exactly the same way in the same places. ORGANISATION objects may also contain personal rather than corporate data. Any attribute that holds name, address, phone, email, nic-hdl, organisation data may hold personal data. So all of this has to be removed from any historical data that is made available. There has never even been any best common practice guidelines saying where personal and corporate data should/should not be used. Except for "abuse-c:". When we implemented that we clearly stated that it should NOT be personal data and will always be made publicly available without any obfuscation. What you end up with is a bare bones object. For people trying to research historical links between objects that existed at some point in history all those links have been removed. If we move towards removing personal data from the database, say we deprecate the PERSON object, then nic-hdls will no longer identify any individual. In that case there would be no need to remove them from historical data. As for address, emails and phone, these would still have to be removed. To preserve the links between objects in historical data they could be replaced by unique keys. In a one time update all addresses, emails, phones etc could be assigned a unique key which can be added to versions of objects in the database as meta data. When a historical object is queried the key could be shown in place of the actual data. This could be made searchable. That would allow researchers to follow these links across objects and time. Just a few thoughts.... cheersdenis co-chair DB-WG On Wednesday, 18 December 2019, 12:17:12 CET, Sander Steffann <sander@steffann.nl> wrote: Hi,

I suspect Sander and myself have just been volunteered. :-)

👍🏻 Sander

In message <2FB87972-9E7C-4FA2-98F3-4881560E2CF8@ripe.net>, "Daniel Karrenberg" <dfk@ripe.net> wrote:

Indeed we have the history in the database, as we should.

The not-so-good news: current policy is to not make it available because of privacy concerns. Unless there is pressure from the community that is not likely to change soon. I am no lawyer but I expect that this policy could change at least for data that is not personal data which would be good enough for what you seek. But I guess that more than two people have to ask for it. A reasonably concise request from this WG would go a long way.

Please allow me to enthusiastically second the motion on the table. Data wants to be free! Please un-hide and un-chain it and allow a thousand flowers of honesty and accountability to bloom! Regards, rfg

In message <9032D272-96D5-47E5-869F-7044B3B88EFC@ucd.ie>, "Niall O'Reilly" <niall.oreilly@ucd.ie> wrote:

I expect that there will be a "grey area" between what should be open and what needs to be protected, and look to the NCC to make clear where the bounds of this grey area will lie.

There is no "grey area". Why would you even suggest that there is one? Data relating to natural persons falls under GDPR. Corporate data does not. If anyone anywhere within RIPE, RIPE NCC, or Europe generally is having any difficulty distinguishing between natural persons and corporations then I can and will gladly supply numerous photographs in order to assist in illustrating the important and easily recognizable differences for the benefit of any who may still be having difficulties in distinguishing between the two... like numerous domain name registrars that I could quite easily name.

It is important that "privacy issues" is not allowed to become (as in some contexts, "health and safety" already has) a groundless, facile, but yet unassailable reason for refusal.

While I agree with the above sentiment, I'm sorry to have to point out that this ship has already sailed, quite some time ago already, largely if not entirely due to cowardice, lethargy, and an abundance of useless inaction on the part of ICANN. Try getting -any- meaningful WHOIS data for any corporate-registered domain name out of, just to name two examples, either Enom or Alibaba. And good luck with that. More to the point, try to get any answers out of ICANN for why they stand by idly while numerous domain name registrars openly flaunt their ability to utterly ignore their contractual commitments to ICANN (e.g their contractual commitments to run WHOIS servers with actual data in them) even in cases that clearly do not implicate GDPR protections for natural persons. And good luck with that also.

For avoidance of doubt, I am not at all suggesting that the NCC has begun to use either of these phrases in such a way.

And neither am I. But having been stonewalled by multiple -other- bodies of so-called "Internet governance", I can say that I personally do not think that it is entirely inappropriate to make the point that no such body should be using GDPR or any other lame excuse for failing to do its job, or to provide open records, as was the long tradition on the Internet even well before any of these bodies even exited. Regards, rfg

On Wed, Dec 18, 2019 at 03:44:40PM +0100, Gert Doering wrote:

Hi,

On Wed, Dec 18, 2019 at 10:22:21AM +0000, Niall O'Reilly wrote:

...

On 18 Dec 2019, at 9:51, Daniel Karrenberg wrote:

...

The not-so-good news: current policy is to not make it available because of privacy concerns. Unless there is pressure from the community that is not likely to change soon. I am no lawyer but I expect that this policy could change at least for data that is not ???personal data???, which would be good enough for what you seek. But I guess that more than two people have to ask for it. A reasonably concise request from this WG would go a long way.

I'm asking for this, so as to build the number towards "more than two". I hope that the WG will indeed make such a request.

I believe that the data should be open enough to allow the question, "what is the matter with this address block?" (my paraphrase) to be answered, while still protecting personal data.

This.

Count my support too. -- Piotr Strzyżewski