Blocking Access to Personal Data Objects in the RIPE Database
Dear colleagues, At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing — if a user queries for too much personal data, we block their access to everything. We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives: "This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.” Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations. No decision has been made on this issue. We are hoping that it can be further discussed by the community to see if a consensus can be reached. Regards Denis Walker Business Analyst RIPE NCC Database Team
Dear all, In short, yes, I support the proposal. My slightly modified suggestion is: When a given IP address, due to the large number of personal data queries reaches the limit where the NCC would now deny access to any objects, I think it would make sense to fully limit the access to personal data (i.e deny access to it), however, limit the access to other data as if they had been using the --no-personal flag so far. As long as there is no other kind of limitations than the one based on the number of personal data retrieved[*], this boils down to the suggestion below. If at some point other limitations are put in place, like number of queries within a time frame (to mitigate DoS attacks), then this would mean that they are still eligible for limitation if their query rate is too high (this time not due to the personal data involved). Best regards, Janos [*] See RIPE DB AUP (http://www.ripe.net/data-tools/support/documentation/aup).
At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing — if a user queries for too much personal data, we block their access to everything.
We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives:
"This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.”
Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations.
No decision has been made on this issue. We are hoping that it can be further discussed by the community to see if a consensus can be reached.
Regards
Denis Walker Business Analyst RIPE NCC Database Team
On Tue, May 27, 2014 at 01:46:30PM +0200, Janos Zsako wrote: Dear Janos, Denis and All
In short, yes, I support the proposal.
My slightly modified suggestion is:
When a given IP address, due to the large number of personal data queries reaches the limit where the NCC would now deny access to any objects, I think it would make sense to fully limit the access to personal data (i.e deny access to it), however, limit the access to other data as if they had been using the --no-personal flag so far.
As long as there is no other kind of limitations than the one based on the number of personal data retrieved[*], this boils down to the suggestion below. If at some point other limitations are put in place, like number of queries within a time frame (to mitigate DoS attacks), then this would mean that they are still eligible for limitation if their query rate is too high (this time not due to the personal data involved).
I strongly support this idea. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Janos Zsako wrote:
Dear all,
In short, yes, I support the proposal.
Same here. I also, in principle, like the more general idea as outlined below. Although I'd leave it to the NCC to think about and to apply DoS protection. :-) Wilfried.
My slightly modified suggestion is:
When a given IP address, due to the large number of personal data queries reaches the limit where the NCC would now deny access to any objects, I think it would make sense to fully limit the access to personal data (i.e deny access to it), however, limit the access to other data as if they had been using the --no-personal flag so far.
As long as there is no other kind of limitations than the one based on the number of personal data retrieved[*], this boils down to the suggestion below. If at some point other limitations are put in place, like number of queries within a time frame (to mitigate DoS attacks), then this would mean that they are still eligible for limitation if their query rate is too high (this time not due to the personal data involved).
Best regards, Janos
[*] See RIPE DB AUP (http://www.ripe.net/data-tools/support/documentation/aup).
At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing — if a user queries for too much personal data, we block their access to everything.
We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives:
"This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.”
Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations.
No decision has been made on this issue. We are hoping that it can be further discussed by the community to see if a consensus can be reached.
Regards
Denis Walker Business Analyst RIPE NCC Database Team
On 27 May 2014, at 14:33, Wilfried Woeber <Woeber@CC.UniVie.ac.at> wrote:
Janos Zsako wrote:
Dear all,
In short, yes, I support the proposal.
Same here. I also, in principle, like the more general idea as outlined below. Although I'd leave it to the NCC to think about and to apply DoS protection. :-)
I am in full agreement with Wilfried’s comment, supporting the modified limitation to personal data access, and let the operator deal with operational issues Joao
Wilfried.
My slightly modified suggestion is:
When a given IP address, due to the large number of personal data queries reaches the limit where the NCC would now deny access to any objects, I think it would make sense to fully limit the access to personal data (i.e deny access to it), however, limit the access to other data as if they had been using the --no-personal flag so far.
As long as there is no other kind of limitations than the one based on the number of personal data retrieved[*], this boils down to the suggestion below. If at some point other limitations are put in place, like number of queries within a time frame (to mitigate DoS attacks), then this would mean that they are still eligible for limitation if their query rate is too high (this time not due to the personal data involved).
Best regards, Janos
[*] See RIPE DB AUP (http://www.ripe.net/data-tools/support/documentation/aup).
At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing — if a user queries for too much personal data, we block their access to everything.
We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives:
"This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.”
Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations.
No decision has been made on this issue. We are hoping that it can be further discussed by the community to see if a consensus can be reached.
Regards
Denis Walker Business Analyst RIPE NCC Database Team
Hi Denis,
At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing — if a user queries for too much personal data, we block their access to everything. We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives:
"This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.”
Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations.
Sounds like a logical plan. If people ask for too much personal data, stop giving them personal data :) No reason to let them continue to ask for things that wouldn't have affected the rate limiter anyway. Rate limiters should only apply limits to whatever they are measuring the rate of :) Cheers, Sander
Sander Steffann wrote the following on 27/05/2014 13:18:
Hi Denis,
At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing — if a user queries for too much personal data, we block their access to everything. We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives:
"This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.”
Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations.
Sounds like a logical plan. If people ask for too much personal data, stop giving them personal data :) No reason to let them continue to ask for things that wouldn't have affected the rate limiter anyway.
Rate limiters should only apply limits to whatever they are measuring the rate of :)
Just what things should a rate limit limit if a rate limit could limit things? Doesn't really work, however I think the right approach has been outlined here. What we're interested in is restricting access to personal data, not to the database. Brian
I agree implement this like Dennis recommendation below. // Andreas Andreas Larsen IP-Only AB | Postadress: 753 81 UPPSALA | Besöksadress Uppsala: S:t Persg 6 Besöksadress Stockholm: N Stationsg 69 | Vxl: +46 18 843 10 00 | Mobil +46 70 843 10 56 www.ip-only.se 27 maj 2014 kl. 15:50 skrev Brian Nisbet <brian.nisbet@heanet.ie>:
Sander Steffann wrote the following on 27/05/2014 13:18:
Hi Denis,
At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing — if a user queries for too much personal data, we block their access to everything. We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives:
"This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.”
Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations.
Sounds like a logical plan. If people ask for too much personal data, stop giving them personal data :) No reason to let them continue to ask for things that wouldn't have affected the rate limiter anyway.
Rate limiters should only apply limits to whatever they are measuring the rate of :)
Just what things should a rate limit limit if a rate limit could limit things?
Doesn't really work, however I think the right approach has been outlined here. What we're interested in is restricting access to personal data, not to the database.
Brian
participants (8)
-
Andreas Larsen -
Brian Nisbet -
Denis Walker -
Janos Zsako -
João Damas -
Piotr Strzyzewski -
Sander Steffann -
Wilfried Woeber