This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[ncc-services-wg] [db-wg] Blocking Access to Personal Data Objects in the RIPE Database
- Previous message (by thread): [ncc-services-wg] [db-wg] Blocking Access to Personal Data Objects in the RIPE Database
- Next message (by thread): [ncc-services-wg] Blocking Access to Personal Data Objects in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
João Damas
joao at bondis.org
Wed May 28 11:01:23 CEST 2014
On 27 May 2014, at 14:33, Wilfried Woeber <Woeber at 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 >>> >>> >>> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: </ripe/mail/archives/ncc-services-wg/attachments/20140528/b6f9adfc/attachment.sig>
- Previous message (by thread): [ncc-services-wg] [db-wg] Blocking Access to Personal Data Objects in the RIPE Database
- Next message (by thread): [ncc-services-wg] Blocking Access to Personal Data Objects in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]