Locking unmaintained PERSON and ROLE objects in the RIPE Database
Dear colleagues, The RIPE NCC Executive Board (EB) endorsed a proposal on how to deal with a vulnerability for RIPE Database users. Following their advice, the RIPE NCC proactively locked 848,986 unmaintained PERSON objects and 1,206 unmaintained ROLE objects on 6 April 2016. Since reaching the last /8, IPv4 address space has become more susceptible to hijacking. Unmaintained PERSON and ROLE objects are highly at risk of being found and hijacked. In addition, unmaintained PERSON and ROLE objects are an issue with regards to data protection obligations. The potential impact of abuse led us to consult with the EB on this intermediary solution before engaging with the community on the next steps. Exposing this issue without taking adequate measures would have left the RIPE NCC liable to third party damages. The proposed solution we outline below is a starting point, to be discussed by the community. Background: =========== Since 2010 it has been mandatory to protect PERSON and ROLE objects in the RIPE Database using a maintainer on "mnt-by:". A large number of PERSON and ROLE objects dating from before 2010 are still not protected in this way. Objects can be created that reference these unmaintained objects, but doing so will generate a warning. In recent years, given the scarcity of IPv4 address space, there is a higher risk of people searching for unmaintained PERSON or ROLE objects in order to pose as a resource holder to sell IPv4 space. In the case of legacy space, this could take place outside the view of the RIPE NCC if the address space is not registered with the RIPE NCC. Proposal: ========= 1) All unmaintained ROLE and PERSON objects are now locked. As the RIPE NCC will not be able to correctly check all claims on unmaintained database objects, unlocking is not available. Offering to unlock these objects could leave the RIPE NCC liable to third party damages if due diligence is not followed. 2) Furthermore, the RIPE NCC modifies the existing warning about referencing unmaintained persons/roles to a similar warning about referencing locked persons/roles. 3a) The locked objects can remain as they are. In time, all locked PERSON or ROLE objects no longer referenced by other objects could be automatically deleted: the current thinking is a 180-day deletion timeout for these locked, unreferenced objects. 3b) If there is an operational need, new PERSON or ROLE objects should be created by the object owners. This solution puts control back into the hands of the object owners. The user can follow the existing process for creating and referencing new objects. If there is a use case for supporting bulk migrations where a reference to a locked PERSON or ROLE object should be replaced, the RIPE NCC can create a wizard in the RIPE Database webupdates section of www.ripe.net <http://www.ripe.net/>. We look forward to your feedback. Kind regards, Trudy Prins Manager Software Engineering RIPE NCC
On 07/04/2016 11:23, Trudy Prins wrote: Can you detail what attempt was performed to try to contact the person or role object? Thanks, Hank
Dear colleagues,
The RIPE NCC Executive Board (EB) endorsed a proposal on how to deal with a vulnerability for RIPE Database users. Following their advice, the RIPE NCC proactively locked 848,986 unmaintained PERSON objects and 1,206 unmaintained ROLE objects on 6 April 2016.
Since reaching the last /8, IPv4 address space has become more susceptible to hijacking. Unmaintained PERSON and ROLE objects are highly at risk of being found and hijacked. In addition, unmaintained PERSON and ROLE objects are an issue with regards to data protection obligations.
The potential impact of abuse led us to consult with the EB on this intermediary solution before engaging with the community on the next steps. Exposing this issue without taking adequate measures would have left the RIPE NCC liable to third party damages.
The proposed solution we outline below is a starting point, to be discussed by the community.
Background: ===========
Since 2010 it has been mandatory to protect PERSON and ROLE objects in the RIPE Database using a maintainer on "mnt-by:". A large number of PERSON and ROLE objects dating from before 2010 are still not protected in this way.
Objects can be created that reference these unmaintained objects, but doing so will generate a warning.
In recent years, given the scarcity of IPv4 address space, there is a higher risk of people searching for unmaintained PERSON or ROLE objects in order to pose as a resource holder to sell IPv4 space. In the case of legacy space, this could take place outside the view of the RIPE NCC if the address space is not registered with the RIPE NCC.
Proposal: =========
1) All unmaintained ROLE and PERSON objects are now locked. As the RIPE NCC will not be able to correctly check all claims on unmaintained database objects, unlocking is not available. Offering to unlock these objects could leave the RIPE NCC liable to third party damages if due diligence is not followed.
2) Furthermore, the RIPE NCC modifies the existing warning about referencing unmaintained persons/roles to a similar warning about referencing locked persons/roles.
3a) The locked objects can remain as they are. In time, all locked PERSON or ROLE objects no longer referenced by other objects could be automatically deleted: the current thinking is a 180-day deletion timeout for these locked, unreferenced objects.
3b) If there is an operational need, new PERSON or ROLE objects should be created by the object owners. This solution puts control back into the hands of the object owners. The user can follow the existing process for creating and referencing new objects. If there is a use case for supporting bulk migrations where a reference to a locked PERSON or ROLE object should be replaced, the RIPE NCC can create a wizard in the RIPE Database webupdates section of www.ripe.net <http://www.ripe.net>.
We look forward to your feedback.
Kind regards,
Trudy Prins Manager Software Engineering RIPE NCC
Hi Hank, It was preferable not to contact the affected parties for the following reasons: - we could not verify if the email address was accurate (it was possible to change without authentication until this became mandatory). - the RIPE NCC is not able to correctly check all claims on unmaintained database objects, it is not possible to assist users to unlock these objects. - There is a substantial operational burden on the RIPE NCC to respond to queries resulting from a mass notification (one quarter of the 850,000 affected objects contained an email address). I hope this clarifies the decision. Regards Ed Shryane RIPE NCC
On 7 Apr 2016, at 21:31, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
On 07/04/2016 11:23, Trudy Prins wrote:
Can you detail what attempt was performed to try to contact the person or role object?
Thanks, Hank
Dear colleagues,
The RIPE NCC Executive Board (EB) endorsed a proposal on how to deal with a vulnerability for RIPE Database users. Following their advice, the RIPE NCC proactively locked 848,986 unmaintained PERSON objects and 1,206 unmaintained ROLE objects on 6 April 2016.
Since reaching the last /8, IPv4 address space has become more susceptible to hijacking. Unmaintained PERSON and ROLE objects are highly at risk of being found and hijacked. In addition, unmaintained PERSON and ROLE objects are an issue with regards to data protection obligations.
The potential impact of abuse led us to consult with the EB on this intermediary solution before engaging with the community on the next steps. Exposing this issue without taking adequate measures would have left the RIPE NCC liable to third party damages.
The proposed solution we outline below is a starting point, to be discussed by the community.
Background: ===========
Since 2010 it has been mandatory to protect PERSON and ROLE objects in the RIPE Database using a maintainer on "mnt-by:". A large number of PERSON and ROLE objects dating from before 2010 are still not protected in this way.
Objects can be created that reference these unmaintained objects, but doing so will generate a warning.
In recent years, given the scarcity of IPv4 address space, there is a higher risk of people searching for unmaintained PERSON or ROLE objects in order to pose as a resource holder to sell IPv4 space. In the case of legacy space, this could take place outside the view of the RIPE NCC if the address space is not registered with the RIPE NCC.
Proposal: =========
1) All unmaintained ROLE and PERSON objects are now locked. As the RIPE NCC will not be able to correctly check all claims on unmaintained database objects, unlocking is not available. Offering to unlock these objects could leave the RIPE NCC liable to third party damages if due diligence is not followed.
2) Furthermore, the RIPE NCC modifies the existing warning about referencing unmaintained persons/roles to a similar warning about referencing locked persons/roles.
3a) The locked objects can remain as they are. In time, all locked PERSON or ROLE objects no longer referenced by other objects could be automatically deleted: the current thinking is a 180-day deletion timeout for these locked, unreferenced objects.
3b) If there is an operational need, new PERSON or ROLE objects should be created by the object owners. This solution puts control back into the hands of the object owners. The user can follow the existing process for creating and referencing new objects. If there is a use case for supporting bulk migrations where a reference to a locked PERSON or ROLE object should be replaced, the RIPE NCC can create a wizard in the RIPE Database webupdates section of www.ripe.net <http://www.ripe.net/>.
We look forward to your feedback.
Kind regards,
Trudy Prins Manager Software Engineering RIPE NCC
On Fri, 8 Apr 2016, Edward Shryane wrote:
Hi Hank,
It was preferable not to contact the affected parties for the following reasons:
- we could not verify if the email address was accurate (it was possible to change without authentication until this became mandatory).
Even more so, it was not possible to change without adding a maintainer. I know that we lost maintainer on some more specific inetnums around 2000 when that was introduced. So I would like to say it's about time. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
On Thu, Apr 07, 2016 at 10:23:16AM +0200, Trudy Prins wrote:
The RIPE NCC Executive Board (EB) endorsed a proposal on how to deal with a vulnerability for RIPE Database users. Following their advice, the RIPE NCC proactively locked 848,986 unmaintained PERSON objects and 1,206 unmaintained ROLE objects on 6 April 2016.
this sounds like a very sensible move to me. Of these ~850.000 objects, how many are referenced by objects from more than a single maintainer?
2) Furthermore, the RIPE NCC modifies the existing warning about referencing unmaintained persons/roles to a similar warning about referencing locked persons/roles.
Assuming that unmaintained objects ought to disappear and at the same time understanding that an immediate hard failure might interfere badly with established running code on the side of an LIR, there should be incentives to migrate. As a start, new references to unmaintained objects could be avoided.
3a) The locked objects can remain as they are. In time, all locked PERSON or ROLE objects no longer referenced by other objects could be automatically deleted: the current thinking is a 180-day deletion timeout for these locked, unreferenced objects.
From a data protection perspective, this cool down phase appears rather long, especially given that even after following (3b) there's no proposed way to actively delete the locked (and re-instantiated) object. What's the perceived drawback of few days only?
-Peter
Peter Koch wrote:
From a data protection perspective, this cool down phase appears rather long, especially given that even after following (3b) there's no proposed way to actively delete the locked (and re-instantiated) object. What's the perceived drawback of few days only?
Is there a particular hurry to delete these objects? 180 days sounds fine to me. Nick
On Fri, Apr 08, 2016 at 12:15:29PM +0100, Nick Hilliard wrote:
Peter Koch wrote:
From a data protection perspective, this cool down phase appears rather long, especially given that even after following (3b) there's no proposed way to actively delete the locked (and re-instantiated) object. What's the perceived drawback of few days only?
Is there a particular hurry to delete these objects? 180 days sounds fine to me.
I was one of the people suggestion this 180 days value, mostly because it is hard to assess what tangible benefits a shorter period would offer. I envision that 180 days is long enough to cover gaps in business processes between an object becoming unreferenced, remaining orphaned for a period (for instance maybe during a migration), and subsequently being attached to a new object again. Admittedly its suggested so to stay on the cautious side. Kind regards, Job
On Fri, Apr 08, 2016 at 12:15:29PM +0100, Nick Hilliard wrote:
From a data protection perspective, this cool down phase appears rather long, especially given that even after following (3b) there's no proposed way to actively delete the locked (and re-instantiated) object. What's the perceived drawback of few days only?
Is there a particular hurry to delete these objects? 180 days sounds fine to me.
From a data protection perspective, you don't need a reason to delete, you'd need a reason to keep, so the "hurry" starts as soon as the last reference is revoked. Is there a substantive risk? Maybe not. I'd still like to understand what purpose that six months period is supposed to serve.
-Peter
Peter Koch writes:
From a data protection perspective, you don't need a reason to delete, you'd need a reason to keep, so the "hurry" starts as soon as the last reference is revoked. Is there a substantive risk? Maybe not. I'd still like to understand what purpose that six months period is supposed to serve.
The last time I looked (10 years or so ago) the Ducth law/guidelines(?) stated that date should be removed 5 years after it doesn't has any function. I think one can find that at something like <https://autoriteitpersoonsgegevens.nl>. jaap
HI All Sorry Trudy but what you have done is not the answer to the problem you have posed. Through your total lack of understanding of how the database works, all you have done is create more problems. In fact I am surprised YOU actually made an announcement about the database given how little you understand it, despite starting as customer support for the database. OK lets look at the problem and its real causes. You state that 'people' can hijack address space by finding these unmaintained PERSON or ROLE objects, modifying them and posing as the 'owners' of the address space. 'owner' being a consequence of the gold mine created over something that no one ever owned before and should still not own. So how do they claim to be the owner? They change the details in the PERSON object, including the PERSON name, and maybe add their own MNTNER to it. But the key element here is the name. In the past you could not change the PERSON object name. This is a change that was implemented a couple of years ago and has led to this current issue. ONLY by changing the name of the PERSON object can you claim to be the 'owner' of this address space. If you can't change the name and you can't produce any ID to show you are the named person, then you have no claim over the address space. Hijacking in this way is not possible. So if you had rolled back that change to allow changes to the PERSON object name you would have fixed this problem. What you have now done is create a massive panic. You have locked almost a million objects with no possibility of substantiating the owners of those objects. You have created a huge redundancy of stale data in the database. Everything still works as it did with these objects locked. But we know from experience no one will now bother to 'fix' any of these objects. No one will be able to update them and few people will bother to replace them. So this will just remain as stale data for many years. And there is nothing the RIPE NCC can do about any of this referenced, stale data now. It will just sit there and you have no idea if it is still valid or not. Even if anyone does replace the locked object, unless you have re-enabled the automatic cleanup of unreferenced objects, which has been disabled for many years, the replaced objects will just persist indefinitely. The automatic cleanup used to delete unreferenced objects after 90 days. That is the time period that was agreed by the community. The fact that you are now talking about 180 days shows that the past community decisions have been lost in the mists of time. The points about data protection are not valid. Anyone can reference any PERSON or ROLE object in any object to give the impression of a connection. Anyone can create a copy of your PERSON object with all the same details including the name and make references to this object as if it was you and you have no control over this and not even any knowledge that it has been done. I will say this just to make it a matter of public record, even though I know no one will acknowledge the point or even make any reference to this point, but these problems are a consequence of an outdated data model that absolutely no one believes needs even to be reviewed. I have worked with this database for 15 years looking at it from every angle and I know it is not possible to fix the data protection issues with this data model, even though no one believes me or will even engage with me to discuss it openly. So much for an alleged 'open, transparent, bottom up process'.... In reality it is a top down, cartel driven, self interest (gold mine) decision making body that few new members feel able to contest on these antiquated mailing lists that are totally unrepresentative of the wider database user community. I know 'people' will hate me for saying this and I hate the thought of Donald J Trump becoming the US president, but I agree with one thing he says....sometimes you need to say things that are not pc and go against the establishment because this is how it really is... cheers denis On 07/04/2016 10:23, Trudy Prins wrote:
Dear colleagues,
The RIPE NCC Executive Board (EB) endorsed a proposal on how to deal with a vulnerability for RIPE Database users. Following their advice, the RIPE NCC proactively locked 848,986 unmaintained PERSON objects and 1,206 unmaintained ROLE objects on 6 April 2016.
Since reaching the last /8, IPv4 address space has become more susceptible to hijacking. Unmaintained PERSON and ROLE objects are highly at risk of being found and hijacked. In addition, unmaintained PERSON and ROLE objects are an issue with regards to data protection obligations.
The potential impact of abuse led us to consult with the EB on this intermediary solution before engaging with the community on the next steps. Exposing this issue without taking adequate measures would have left the RIPE NCC liable to third party damages.
The proposed solution we outline below is a starting point, to be discussed by the community.
Background: ===========
Since 2010 it has been mandatory to protect PERSON and ROLE objects in the RIPE Database using a maintainer on "mnt-by:". A large number of PERSON and ROLE objects dating from before 2010 are still not protected in this way.
Objects can be created that reference these unmaintained objects, but doing so will generate a warning.
In recent years, given the scarcity of IPv4 address space, there is a higher risk of people searching for unmaintained PERSON or ROLE objects in order to pose as a resource holder to sell IPv4 space. In the case of legacy space, this could take place outside the view of the RIPE NCC if the address space is not registered with the RIPE NCC.
Proposal: =========
1) All unmaintained ROLE and PERSON objects are now locked. As the RIPE NCC will not be able to correctly check all claims on unmaintained database objects, unlocking is not available. Offering to unlock these objects could leave the RIPE NCC liable to third party damages if due diligence is not followed.
2) Furthermore, the RIPE NCC modifies the existing warning about referencing unmaintained persons/roles to a similar warning about referencing locked persons/roles.
3a) The locked objects can remain as they are. In time, all locked PERSON or ROLE objects no longer referenced by other objects could be automatically deleted: the current thinking is a 180-day deletion timeout for these locked, unreferenced objects.
3b) If there is an operational need, new PERSON or ROLE objects should be created by the object owners. This solution puts control back into the hands of the object owners. The user can follow the existing process for creating and referencing new objects. If there is a use case for supporting bulk migrations where a reference to a locked PERSON or ROLE object should be replaced, the RIPE NCC can create a wizard in the RIPE Database webupdates section of www.ripe.net <http://www.ripe.net/>.
We look forward to your feedback.
Kind regards,
Trudy Prins Manager Software Engineering RIPE NCC
On Tue, Apr 12, 2016 at 12:52:30AM +0200, denis wrote: Denis
So how do they claim to be the owner? They change the details in the PERSON object, including the PERSON name, and maybe add their own MNTNER to it. But the key element here is the name. In the past you could not change the PERSON object name. This is a change that was implemented a couple of years ago and has led to this current issue. ONLY by changing the name of the PERSON object can you claim to be the 'owner' of this address space. If you can't change the name and you can't produce any ID to show you are the named person, then you have no claim over the address space. Hijacking in this way is not possible. So if you had rolled back that change to allow changes to the PERSON object name you would have fixed this problem.
Leaving aside rest of your email, this is plain wishful thinking. It is not a problem to find and pay/bribe someone with the same name to be a mere front man. Or change a name at some jurisdictions. Or marry someone and then change the name. This has been "invented" years ago. For those who understand a bit of polish, a cut from the well known polish commedy from 1980 with the same idea: https://youtu.be/ApLfbr89ssk?t=1m18s Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi Piotr On 13/04/2016 22:18, Piotr Strzyzewski wrote:
On Tue, Apr 12, 2016 at 12:52:30AM +0200, denis wrote:
Denis
So how do they claim to be the owner? They change the details in the PERSON object, including the PERSON name, and maybe add their own MNTNER to it. But the key element here is the name. In the past you could not change the PERSON object name. This is a change that was implemented a couple of years ago and has led to this current issue. ONLY by changing the name of the PERSON object can you claim to be the 'owner' of this address space. If you can't change the name and you can't produce any ID to show you are the named person, then you have no claim over the address space. Hijacking in this way is not possible. So if you had rolled back that change to allow changes to the PERSON object name you would have fixed this problem.
Leaving aside rest of your email, this is plain wishful thinking.
It is not a problem to find and pay/bribe someone with the same name to be a mere front man. Or change a name at some jurisdictions. Or marry someone and then change the name. This has been "invented" years ago.
Maybe I am missing something here. But considering what you have just said....what have you fixed by locking almost a million objects? Consider 3 address blocks: 1/ admin-c and tech-c are properly maintained 2/ admin-c and tech-c were unmaintained 3/ admin-c and tech-c are now locked If you consider that a hijacker can 'get' id to show they are the referenced person, what difference does it make which of these three cases the address space is? The locked is now the same as properly maintained to a hijacker. So instead of simply changing the name they have to 'get' id. So you have solved nothing, but created a massive, long term problem. In fact you have created a new data protection problem. Almost a million personal data sets cannot be changed by the data subject. The RIPE NCC will not recognise anyone as the 'person' referenced in one of these objects. If they are not in a position to remove the reference what will you do? More generally you have a million personal data sets that you cannot claim to be accurate personal data. But as long as they remain referenced there is nothing the RIPE NCC can do about it. So I will say again, the action you have taken is not the answer to this problem. cheers denis
For those who understand a bit of polish, a cut from the well known polish commedy from 1980 with the same idea: https://youtu.be/ApLfbr89ssk?t=1m18s
Piotr
On Wed, Apr 13, 2016 at 11:42:45PM +0200, denis wrote: Denis
So how do they claim to be the owner? They change the details in the PERSON object, including the PERSON name, and maybe add their own MNTNER to it. But the key element here is the name. In the past you could not change the PERSON object name. This is a change that was implemented a couple of years ago and has led to this current issue. ONLY by changing the name of the PERSON object can you claim to be the 'owner' of this address space. If you can't change the name and you can't produce any ID to show you are the named person, then you have no claim over the address space. Hijacking in this way is not possible. So if you had rolled back that change to allow changes to the PERSON object name you would have fixed this problem.
Leaving aside rest of your email, this is plain wishful thinking.
It is not a problem to find and pay/bribe someone with the same name to be a mere front man. Or change a name at some jurisdictions. Or marry someone and then change the name. This has been "invented" years ago.
Maybe I am missing something here. But considering what you have just said....what have you fixed by locking almost a million objects?
I did not say anything about solving any problem. Just to remind what you have said: "So if you had rolled back that change to allow changes to the PERSON object name you would have fixed this problem."
Consider 3 address blocks: 1/ admin-c and tech-c are properly maintained 2/ admin-c and tech-c were unmaintained 3/ admin-c and tech-c are now locked
If you consider that a hijacker can 'get' id to show they are the referenced person, what difference does it make which of these three cases the address space is?
The locked is now the same as properly maintained to a hijacker. So instead of simply changing the name they have to 'get' id.
So you have solved nothing, but created a massive, long term problem. In fact you have created a new data protection problem. Almost a million personal data sets cannot be changed by the data subject. The RIPE NCC will not recognise anyone as the 'person' referenced in one of these objects. If they are not in a position to remove the reference what will you do? More generally you have a million personal data sets that you cannot claim to be accurate personal data. But as long as they remain referenced there is nothing the RIPE NCC can do about it.
So I will say again, the action you have taken is not the answer to this problem.
Taking your arguments stated above, I once again (this time more clear) say that rolling back the change to allow changes to the PERSON object name would _not_ have fixed the problem. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
HI Piotr On 13/04/2016 23:50, Piotr Strzyzewski wrote:
On Wed, Apr 13, 2016 at 11:42:45PM +0200, denis wrote:
Denis
So how do they claim to be the owner? They change the details in the PERSON object, including the PERSON name, and maybe add their own MNTNER to it. But the key element here is the name. In the past you could not change the PERSON object name. This is a change that was implemented a couple of years ago and has led to this current issue. ONLY by changing the name of the PERSON object can you claim to be the 'owner' of this address space. If you can't change the name and you can't produce any ID to show you are the named person, then you have no claim over the address space. Hijacking in this way is not possible. So if you had rolled back that change to allow changes to the PERSON object name you would have fixed this problem.
Leaving aside rest of your email, this is plain wishful thinking.
It is not a problem to find and pay/bribe someone with the same name to be a mere front man. Or change a name at some jurisdictions. Or marry someone and then change the name. This has been "invented" years ago.
Maybe I am missing something here. But considering what you have just said....what have you fixed by locking almost a million objects?
I did not say anything about solving any problem.
I thought solving problems was the goal...
Just to remind what you have said:
"So if you had rolled back that change to allow changes to the PERSON object name you would have fixed this problem."
Consider 3 address blocks: 1/ admin-c and tech-c are properly maintained 2/ admin-c and tech-c were unmaintained 3/ admin-c and tech-c are now locked
If you consider that a hijacker can 'get' id to show they are the referenced person, what difference does it make which of these three cases the address space is?
The locked is now the same as properly maintained to a hijacker. So instead of simply changing the name they have to 'get' id.
So you have solved nothing, but created a massive, long term problem. In fact you have created a new data protection problem. Almost a million personal data sets cannot be changed by the data subject. The RIPE NCC will not recognise anyone as the 'person' referenced in one of these objects. If they are not in a position to remove the reference what will you do? More generally you have a million personal data sets that you cannot claim to be accurate personal data. But as long as they remain referenced there is nothing the RIPE NCC can do about it.
So I will say again, the action you have taken is not the answer to this problem.
Taking your arguments stated above, I once again (this time more clear) say that rolling back the change to allow changes to the PERSON object name would _not_ have fixed the problem.
Maybe not, but it would have been a harmless change. Your action has created massive, long term, legal problems and a lot of inconvenience to members. cheers denis
Piotr
On Thu, Apr 14, 2016 at 12:00:45AM +0200, denis wrote: Denis
Taking your arguments stated above, I once again (this time more clear) say that rolling back the change to allow changes to the PERSON object name would _not_ have fixed the problem.
Maybe not, but it would have been a harmless change. Your action has
This change has been discussed and expected in this community at least from the year 2000. And has been checked by You in 2014 with RIPE NCC's legal team. I haven't seen any technical, legal, procedural (nor any other) objections raised by You under issue 221 (https://github.com/RIPE-NCC/whois/issues/221). What has changed during last 1.5 year? Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
HI Piotr You really are barking up the wrong tree here. On 14/04/2016 00:31, Piotr Strzyzewski wrote:
On Thu, Apr 14, 2016 at 12:00:45AM +0200, denis wrote:
Denis
Taking your arguments stated above, I once again (this time more clear) say that rolling back the change to allow changes to the PERSON object name would _not_ have fixed the problem.
Maybe not, but it would have been a harmless change. Your action has
This change has been discussed and expected in this community at least from the year 2000.
For a start this database with this (broken) data model did not exist in 2000. It was released to production in April 2001. And has been checked by You in 2014 with RIPE NCC's
legal team. I haven't seen any technical, legal, procedural (nor any other) objections raised by You under issue 221 (https://github.com/RIPE-NCC/whois/issues/221). What has changed during last 1.5 year?
Issue 221 was about changing the PERSON object name. It was agreed by the RIPE NCC legal team that they saw no problems at that time. What has changed is that you have now identified a hijacking issue. Rolling back that change would have prevented 'easy' hijacking by simply changing the name of an unmaintained PERSON object to your name. By locking the objects they now have to 'get' ID in that name. As you pointed out that seems to be easy, although I have no idea how to do something like that. You seem to be determined to 'prove' I am wrong suggesting rolling back the name change would fix this issue. But you don't seem to accept that the action you have taken has also NOT fixed the problem but caused many more serious problems. cheers denis
Piotr
On Thu, Apr 14, 2016 at 01:07:01AM +0200, denis wrote: Denis
You really are barking up the wrong tree here.
Nice try, but you misinterpret my intentions.
On 14/04/2016 00:31, Piotr Strzyzewski wrote:
On Thu, Apr 14, 2016 at 12:00:45AM +0200, denis wrote:
Denis
Taking your arguments stated above, I once again (this time more clear) say that rolling back the change to allow changes to the PERSON object name would _not_ have fixed the problem.
Maybe not, but it would have been a harmless change. Your action has
This change has been discussed and expected in this community at least from the year 2000.
For a start this database with this (broken) data model did not exist in 2000. It was released to production in April 2001.
Which do not proof that there was no desire/discussion/need for change of the person name even earlier: https://www.ripe.net/ripe/mail/archives/db-wg/2001-January/001512.html
And has been checked by You in 2014 with RIPE NCC's
legal team. I haven't seen any technical, legal, procedural (nor any other) objections raised by You under issue 221 (https://github.com/RIPE-NCC/whois/issues/221). What has changed during last 1.5 year?
Issue 221 was about changing the PERSON object name. It was agreed by the RIPE NCC legal team that they saw no problems at that time. What has changed is that you have now identified a hijacking issue. Rolling back that change would have prevented 'easy' hijacking by simply changing the name of an unmaintained PERSON object to your name. By locking the objects they now have to 'get' ID in that name. As you pointed out that seems to be easy, although I have no idea how to do something like that.
The hijacking issue was there for years. I'm just surprised that it was not raised by you during the discussion of issue 221.
You seem to be determined to 'prove' I am wrong suggesting rolling back the name change would fix this issue. But you don't seem to accept that the action you have taken has also NOT fixed the problem but caused many more serious problems.
Please refrain from suggesting that I have done something. Moreover, keep saying the mantra about causing many more serious problems is neither the proof of this thesis nor the solution to anything. If you know/see something which could seriously improve the quality of the data, security model, business rules, etc, just bring it on the table. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi Piotr On 14/04/2016 08:41, Piotr Strzyzewski wrote:
On Thu, Apr 14, 2016 at 01:07:01AM +0200, denis wrote:
Denis
You really are barking up the wrong tree here.
Nice try, but you misinterpret my intentions.
This is a very condescending remark.
On 14/04/2016 00:31, Piotr Strzyzewski wrote:
On Thu, Apr 14, 2016 at 12:00:45AM +0200, denis wrote:
Denis
Taking your arguments stated above, I once again (this time more clear) say that rolling back the change to allow changes to the PERSON object name would _not_ have fixed the problem.
Maybe not, but it would have been a harmless change. Your action has
This change has been discussed and expected in this community at least from the year 2000.
For a start this database with this (broken) data model did not exist in 2000. It was released to production in April 2001.
Which do not proof that there was no desire/discussion/need for change of the person name even earlier:
https://www.ripe.net/ripe/mail/archives/db-wg/2001-January/001512.html
And has been checked by You in 2014 with RIPE NCC's
legal team. I haven't seen any technical, legal, procedural (nor any other) objections raised by You under issue 221 (https://github.com/RIPE-NCC/whois/issues/221). What has changed during last 1.5 year?
Issue 221 was about changing the PERSON object name. It was agreed by the RIPE NCC legal team that they saw no problems at that time. What has changed is that you have now identified a hijacking issue. Rolling back that change would have prevented 'easy' hijacking by simply changing the name of an unmaintained PERSON object to your name. By locking the objects they now have to 'get' ID in that name. As you pointed out that seems to be easy, although I have no idea how to do something like that.
The hijacking issue was there for years. I'm just surprised that it was not raised by you during the discussion of issue 221.
Again this is another condescending remark. You imply that I should know everything at all times. If you knew about this hijacking issue that you say has been around for years, then as a co-chair of this working group why did you not mention it at the time?
You seem to be determined to 'prove' I am wrong suggesting rolling back the name change would fix this issue. But you don't seem to accept that the action you have taken has also NOT fixed the problem but caused many more serious problems.
Please refrain from suggesting that I have done something.
The whole tone of this thread is one of attack and aggression towards me. You are not discussing the issues but you are discussing me. You are relentlessly pursuing my comments and looking back in history to prove me wrong, instead of trying to move forward. You are doing exactly what you accuse me of.
Moreover, keep saying the mantra about causing many more serious problems is neither the proof of this thesis nor the solution to anything. If you know/see something which could seriously improve the quality of the data, security model, business rules, etc, just bring it on the table.
Sorry but you are missing the point here. It is not a thesis and I have stated the serious problem. I was part of the Data Protection Task Force many years ago. I spent a lot of time with the RIPE NCC's lawyers discussing the data protection issues around the RIPE Database. The action you have taken HAS already created a data protection issue. There are now about a million personal data sets in the database that the data subjects cannot change. The RIPE NCC has stated it will not unlock any of these objects as they cannot be sure who they refer to. The RIPE NCC, as Data Controller of this database has a million personal data sets in their database that they cannot assert contain accurate data and they have prevented the data subjects from updating their personal data. The RIPE NCC also, even as Data Controller, cannot do anything to fix or replace these personal data sets. Now I will bring some suggestions to the table to fix this issue. First I would like the RIPE NCC legal team to review this situation and publish to this list their considerations. Secondly I suggest the RIPE NCC unlocks these objects, as it makes no difference to the hijacking situation that you say has been around for years anyway. Third I suggest the RIPE NCC aggressively pursues the members who reference these unmaintained personal objects and pushes them to either maintain them or replace them. Finally I would say that for an issue that the DB WG co-chairs have known to have been around for many years, I don't see why it needed a secret, back room discussion and a sudden announcement that the RIPE NCC has locked a million objects without any community discussion. As I am not receiving the emails in this discussion from the DB WG mailing list, I think you may have already blocked them. So I have cc'd Athina directly for a legal comment. cheers denis
Piotr
On Thu, Apr 14, 2016 at 01:31:20PM +0200, denis wrote: Dear Denis
On 14/04/2016 08:41, Piotr Strzyzewski wrote:
On Thu, Apr 14, 2016 at 01:07:01AM +0200, denis wrote:
Denis
You really are barking up the wrong tree here.
Nice try, but you misinterpret my intentions.
This is a very condescending remark.
I could personally perceive the same way your comment about barking up the wrong tree. Maybe one of us is oversensitive. Or this is plain language barrier.
The hijacking issue was there for years. I'm just surprised that it was not raised by you during the discussion of issue 221.
Again this is another condescending remark. You imply that I should know everything at all times. If you knew about this hijacking issue that you
Not at all. I just declare that I'm surprised.
say has been around for years, then as a co-chair of this working group why did you not mention it at the time?
Oh. I did.
You seem to be determined to 'prove' I am wrong suggesting rolling back the name change would fix this issue. But you don't seem to accept that the action you have taken has also NOT fixed the problem but caused many more serious problems.
Please refrain from suggesting that I have done something.
The whole tone of this thread is one of attack and aggression towards me. You are not discussing the issues but you are discussing me. You are relentlessly pursuing my comments and looking back in history to prove me wrong, instead of trying to move forward. You are doing exactly what you accuse me of.
I do not accuse you of anything.
Moreover, keep saying the mantra about causing many more serious problems is neither the proof of this thesis nor the solution to anything. If you know/see something which could seriously improve the quality of the data, security model, business rules, etc, just bring it on the table.
Sorry but you are missing the point here. It is not a thesis and I have stated the serious problem. I was part of the Data Protection Task Force many years ago. I spent a lot of time with the RIPE NCC's lawyers discussing the data protection issues around the RIPE Database.
The action you have taken HAS already created a data protection issue.
Once again - please refrain from writing that I have done something here. At least that is how I understand constant usage of the word "you".
There are now about a million personal data sets in the database that the data subjects cannot change. The RIPE NCC has stated it will not unlock any of these objects as they cannot be sure who they refer to. The RIPE NCC, as Data Controller of this database has a million personal data sets in their database that they cannot assert contain accurate data and they have prevented the data subjects from updating their personal data. The RIPE NCC also, even as Data Controller, cannot do anything to fix or replace these personal data sets.
If this is data protection issue, I suggest to notice the Dutch Data Protection Authority.
Now I will bring some suggestions to the table to fix this issue. First I would like the RIPE NCC legal team to review this situation and publish to this list their considerations. Secondly I suggest the RIPE NCC unlocks these objects, as it makes no difference to the hijacking situation that you say has been around for years anyway. Third I suggest the RIPE NCC aggressively pursues the members who reference these unmaintained personal objects and pushes them to either maintain them or replace them.
Now, this is something.
Finally I would say that for an issue that the DB WG co-chairs have known to have been around for many years, I don't see why it needed a secret, back room discussion and a sudden announcement that the RIPE NCC has locked a million objects without any community discussion.
As I am not receiving the emails in this discussion from the DB WG mailing list, I think you may have already blocked them. So I have cc'd Athina directly for a legal comment.
Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On 2016 Apr 14 (Thu) at 13:56:34 +0200 (+0200), Piotr Strzyzewski wrote: :Once again - please refrain from writing that I have done something :here. At least that is how I understand constant usage of the word :"you". In English, "you" can be either 2nd person singular, or 2nd person plural. I personally could use it to refer to any or all of the DB-WG, the DB-WG Admins, RIPE, or the RIPE NCC.
On Thu, Apr 14, 2016 at 02:02:42PM +0200, Peter Hessler wrote:
In English, "you" can be either 2nd person singular, or 2nd person plural. I personally could use it to refer to any or all of the DB-WG, the DB-WG Admins, RIPE, or the RIPE NCC.
Semantics and accusations aside, Denis is not wrong on the issue of the locked objects.
From a data protection PoV, leaving them locked but visible is *exactly* the wrong thing to do. If they are non-verifiable, delete them. Do it NOW. If that causes issues with objects that reference the locekd objects, replace the reference with a template object or something until it can be replaced.
rgds, Sascha Luck
On Thu, Apr 14, 2016 at 01:08:44PM +0100, Sascha Luck [ml] wrote:
On Thu, Apr 14, 2016 at 02:02:42PM +0200, Peter Hessler wrote:
In English, "you" can be either 2nd person singular, or 2nd person plural. I personally could use it to refer to any or all of the DB-WG, the DB-WG Admins, RIPE, or the RIPE NCC.
Semantics and accusations aside, Denis is not wrong on the issue of the locked objects.
From a data protection PoV, leaving them locked but visible is *exactly* the wrong thing to do. If they are non-verifiable, delete them. Do it NOW. If that causes issues with objects that reference the locekd objects, replace the reference with a template object or something until it can be replaced.
Good point. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On Thu, Apr 14, 2016 at 02:02:42PM +0200, Peter Hessler wrote:
On 2016 Apr 14 (Thu) at 13:56:34 +0200 (+0200), Piotr Strzyzewski wrote: :Once again - please refrain from writing that I have done something :here. At least that is how I understand constant usage of the word :"you".
In English, "you" can be either 2nd person singular, or 2nd person plural. I personally could use it to refer to any or all of the DB-WG, the DB-WG Admins, RIPE, or the RIPE NCC.
Thanks. Till now I have always refered it to the "all" in 2nd person plural. As I said - this could be plain language barrier. ;-) Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Dear Denis, Thank you for your request. Please allow me some time to look into this matter. I will provide you and the list with my comment next week. Kind regards, Athina Fragkouli Head of Legal RIPE NCC On 14/04/16 13:31, denis wrote:
Hi Piotr
On 14/04/2016 08:41, Piotr Strzyzewski wrote:
On Thu, Apr 14, 2016 at 01:07:01AM +0200, denis wrote:
Denis
You really are barking up the wrong tree here.
Nice try, but you misinterpret my intentions.
This is a very condescending remark.
On 14/04/2016 00:31, Piotr Strzyzewski wrote:
On Thu, Apr 14, 2016 at 12:00:45AM +0200, denis wrote:
Denis
Taking your arguments stated above, I once again (this time more clear) say that rolling back the change to allow changes to the PERSON object name would _not_ have fixed the problem.
Maybe not, but it would have been a harmless change. Your action has
This change has been discussed and expected in this community at least from the year 2000.
For a start this database with this (broken) data model did not exist in 2000. It was released to production in April 2001.
Which do not proof that there was no desire/discussion/need for change of the person name even earlier:
https://www.ripe.net/ripe/mail/archives/db-wg/2001-January/001512.html
And has been checked by You in 2014 with RIPE NCC's
legal team. I haven't seen any technical, legal, procedural (nor any other) objections raised by You under issue 221 (https://github.com/RIPE-NCC/whois/issues/221). What has changed during last 1.5 year?
Issue 221 was about changing the PERSON object name. It was agreed by the RIPE NCC legal team that they saw no problems at that time. What has changed is that you have now identified a hijacking issue. Rolling back that change would have prevented 'easy' hijacking by simply changing the name of an unmaintained PERSON object to your name. By locking the objects they now have to 'get' ID in that name. As you pointed out that seems to be easy, although I have no idea how to do something like that.
The hijacking issue was there for years. I'm just surprised that it was not raised by you during the discussion of issue 221.
Again this is another condescending remark. You imply that I should know everything at all times. If you knew about this hijacking issue that you say has been around for years, then as a co-chair of this working group why did you not mention it at the time?
You seem to be determined to 'prove' I am wrong suggesting rolling back the name change would fix this issue. But you don't seem to accept that the action you have taken has also NOT fixed the problem but caused many more serious problems.
Please refrain from suggesting that I have done something.
The whole tone of this thread is one of attack and aggression towards me. You are not discussing the issues but you are discussing me. You are relentlessly pursuing my comments and looking back in history to prove me wrong, instead of trying to move forward. You are doing exactly what you accuse me of.
Moreover, keep saying the mantra about causing many more serious problems is neither the proof of this thesis nor the solution to anything. If you know/see something which could seriously improve the quality of the data, security model, business rules, etc, just bring it on the table.
Sorry but you are missing the point here. It is not a thesis and I have stated the serious problem. I was part of the Data Protection Task Force many years ago. I spent a lot of time with the RIPE NCC's lawyers discussing the data protection issues around the RIPE Database.
The action you have taken HAS already created a data protection issue. There are now about a million personal data sets in the database that the data subjects cannot change. The RIPE NCC has stated it will not unlock any of these objects as they cannot be sure who they refer to. The RIPE NCC, as Data Controller of this database has a million personal data sets in their database that they cannot assert contain accurate data and they have prevented the data subjects from updating their personal data. The RIPE NCC also, even as Data Controller, cannot do anything to fix or replace these personal data sets.
Now I will bring some suggestions to the table to fix this issue. First I would like the RIPE NCC legal team to review this situation and publish to this list their considerations. Secondly I suggest the RIPE NCC unlocks these objects, as it makes no difference to the hijacking situation that you say has been around for years anyway. Third I suggest the RIPE NCC aggressively pursues the members who reference these unmaintained personal objects and pushes them to either maintain them or replace them.
Finally I would say that for an issue that the DB WG co-chairs have known to have been around for many years, I don't see why it needed a secret, back room discussion and a sudden announcement that the RIPE NCC has locked a million objects without any community discussion.
As I am not receiving the emails in this discussion from the DB WG mailing list, I think you may have already blocked them. So I have cc'd Athina directly for a legal comment.
cheers denis
Piotr
HI In April 2016 the RIPE NCC announced they had 'locked' 850,000 personal data sets in the RIPE Database. I raised a number of issues and my last set of questions were never answered. As I predicted, the issue has dropped off the table. I will give you the bottom line first: -this action was based on a false premise -it breaks the Dutch data protection rules -it bypasses the RIPE NCC's legal personal data removal procedure -it has left the RIPE NCC (and possibly the Executive Board members personally) liable for consequential losses -it was claimed to be a temporary action but neither the RIPE NCC nor the WG co-chairs have facilitated or driven a discussion with any urgency -it is becoming another of those issues that just drift from year to year with no one pushing for a solution I previously suggested in an email to: 1/ Immediately unlock these objects and revert the responsibility for them back to the resource holders who reference them, as they have no direct maintainer. 2/ Immediately remove any references to unmaintained objects where references to other, maintained, objects fulfil syntax and business rules. 3/ Ensure the auto deletion of unreferenced personal data objects after 90 days is re-enabled. 4/ Aggressively pursue the resource holders who reference the remaining unmaintained objects to maintain or replace them. ----------------------------------------------------------- For those who can't read long emails you can move on now. Following is the detail that supports the bottom line above. From the original announcement: https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005139.html "the RIPE NCC proactively locked 848,986 unmaintained PERSON objects and 1,206 unmaintained ROLE objects on 6 April 2016". The Data Protection Task Force (DPTF) was formed in 2006 and made a final report in 2010 referring to these unmaintained objects. That is not very 'proactive'. "In addition, unmaintained PERSON and ROLE objects are an issue with regards to data protection obligations." If it took 10 years to take action it wasn't much of an issue. "Exposing this issue without taking adequate measures would have left the RIPE NCC liable to third party damages." The issue has been known about for many years without any (adequate) measures being taken. The RIPE NCC could be liable for much worse damages now. "The proposed solution we outline below is a starting point, to be discussed by the community." which like so many other issues raised over the last couple of years has just faded away because no one is monitoring these things or driving them forward. "In recent years, given the scarcity of IPv4 address space, there is a higher risk of people searching for unmaintained PERSON or ROLE objects in order to pose as a resource holder to sell IPv4 space." This perception of risk was totally refuted by Piotr in his message: https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005156.html "All unmaintained ROLE and PERSON objects are now locked. As the RIPE NCC will not be able to correctly check all claims on unmaintained database objects, unlocking is not available." "The locked objects can remain as they are." This bypasses the RIPE NCC's legal personal data removal procedure and breaks data protection rules. "In time, all locked PERSON or ROLE objects no longer referenced by other objects could be automatically deleted" This process may take another 10+ years. It is already 10 years since the DPTF highlighted the issue. "This solution puts control back into the hands of the object owners." Absolute nonsense! The 'object owners' is now the RIPE NCC. The people that matter are the data subjects who are excluded from this process by the refusal of the RIPE NCC to unlock these objects. From the RIPE Database Terms & Conditions: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms Article 6.2 says "The Maintainer is responsible for keeping all data maintained by him accurate and up-to-date, including correct Contact Details." Because the 'urgent security issue' did not exist, the RIPE NCC cannot claim it acted as Data Controller to lock objects that posed a security or hijack risk. So the RIPE NCC has not 'locked' these objects it has simply put it's own MNTNER object as the "mnt-by:" for these objects, thereby becoming the Maintainer. So according to Article 6.2 they have taken over responsibility for the accuracy of these 850k+ objects. The liability exception and indemnity of Article 7.2 applies to the use of the RIPE Database as a service provided by the RIPE NCC. It does not cover the RIPE NCC in regard to it's responsibility for data it managers contained within the RIPE Database. So the RIPE NCC has taken responsibility for 850k+ personal data sets related to people they have no relationship or contact with. They have also made it clear they will not unlock this data as they can't identify any data subject. They have also accepted that this data may be held statically in the database for 'some time'. This breaks every notion of personal data protection. This is currently dubious, stale data that the RIPE NCC cannot do anything about. They have accepted they don't know who it relates to, will not accept anyone's claim it relates to them, will not unlock it, cannot delete it, data subject cannot remove it, don't know if it is accurate, don't know if consent was given to enter it, and everything 'just works' with it sitting there so the members who reference it don't need to do anything. The worst possible, self created scenario. The scale of the issue, almost a million personal data sets, makes this a serious problem. The RIPE NCC's legal analysis: https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005181.html and my unanswered questions on this analysis: https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005182.html "The RIPE NCC is by default the "data controller" of the personal data in the Database (i.e. it has liability by law) but in practice it has no control over all these personal data. The DPTF, representing the RIPE community, decided that this responsibility should be contractually (via the RIPE Database Terms and Conditions) transferred to those that have actual control over the personal data. In the RIPE Database, these persons are identified by the maintainer object (referenced by the “mnt-by:” attribute in any data object)" The fact that the RIPE NCC now maintains these objects means you do control them and therefore by your own definition the RIPE NCC IS liable for this data. "Although the RIPE NCC allowed some time for the community members to add a mandatory "mnt-by:" to their so-far unmaintained personal data, there were still unmaintained personal data in the RIPE Database." This time was 10 years. After that period of time you cannot argue there was any urgency to take action as data controller. "The RIPE NCC was alerted by third parties that this data could be hijacked in order to facilitate illegal activities." This point was discussed with Piotr and he said the risk of hijacking has been known about for many years and has nothing to do with personal data being maintained or not. He said it is very easy to 'get' id to match any maintained personal data in the database. "It was the RIPE NCC's responsibility to inform the RIPE community of this security risk and initiate a community discussion on possible ways to handle it. At the same time, the RIPE NCC could anticipate that if we were merely exposed the security risk without taking any measures to prevent it, we would alert malicious people and the hijacking attempts would increase." The community has known about this risk for decades and any discussion without this action would not have increased any risk of hijacking. You may have initiated a community discussion, but quickly allowed it to fade away without any conclusion or action plan. "Therefore, we considered that locking the objects, until the community could discuss a proper way forward, would be an adequate measure to prevent possible hijacking cases in the meantime," a measure which, as we have already established does not prevent possible hijacking. "This action was in line with the RIPE NCC's obligations by law." If the RIPE NCC thought it had any legal obligation here it was 10 years too late in taking action. "If people would like to have their locked personal data removed from the RIPE Database, they can submit a request to the RIPE NCC." It was made clear in the original announcement that the RIPE NCC will not unlock any of these objects as it is not possible to identify the data subjects. So by what criteria are you going to accept deletion requests? So to sum up the RIPE NCC has created a data protection problem on a massive scale, based on an old and false premise which was approved directly by the executive board and then allowed the issue to just fall off the table. I don't know much about Dutch corporate law but I suspect that could pass some liability onto the members of the board. All you need is one person to point out one of these objects being related to them that did not have their consent to be added, containing inaccurate data that has caused them some consequential loss....the RIPE NCC (and possibly the board members) will be liable for those losses. cheers denis
participants (13)
-
Athina Fragkouli -
Daniel Stolpe -
denis -
Edward Shryane -
Hank Nussbacher -
Jaap Akkerhuis -
Job Snijders -
Nick Hilliard -
Peter Hessler -
Peter Koch -
Piotr Strzyzewski -
Sascha Luck [ml] -
Trudy Prins