From no-reply at ripe.net Mon Nov 5 11:05:10 2012 From: no-reply at ripe.net (Axel Pawlik) Date: Mon, 05 Nov 2012 11:05:10 +0100 Subject: [anti-abuse-wg] RIPE NCC Data Protection Report published Message-ID: <50978F56.6070305@ripe.net> Dear colleagues, To comply with Dutch data protection legislation regarding personal data, the RIPE NCC has developed a legal framework that guarantees the proper and lawful use of personal data. This framework has been established in cooperation with the RIPE community through a task force created for this purpose, the RIPE Data Protection Task Force (DPTF). Recent discussion on this list has suggested that a clear overview of the legal background to the framework and procedures proposed by the DPTF may promote better community understanding of the RIPE Database rules and the justification for them. In the interests of transparency and understanding, the RIPE NCC has produced a report that provides the legal background to the framework and procedures relating to personal data in the RIPE Database and other RIPE NCC services. The RIPE NCC Data Protection Report is available at: https://www.ripe.net/lir-services/ncc/legal/ripe-ncc-data-protection-report The RIPE NCC Data Protection Report was presented to the community at RIPE 65 in October 2012. The presentation can be viewed at: https://ripe65.ripe.net/archives/video/137/ Kind regards, Axel Pawlik Managing Director RIPE NCC From bengan at bag.org Mon Nov 12 18:45:55 2012 From: bengan at bag.org (=?UTF-8?B?QmVuZ3QgR8O2cmTDqW4=?=) Date: Mon, 12 Nov 2012 18:45:55 +0100 Subject: [anti-abuse-wg] abuse-c implementation schedule In-Reply-To: <50856D7C.90606@ripe.net> References: <5084FCAA.6040408@mutluit.com> <5084FFF7.2050003@hovland.cx> <50850240.3020600@powerweb.de> <50856D7C.90606@ripe.net> Message-ID: <50A135D3.8090300@bag.org> 2012-10-22 17:59, Denis Walker skrev: > Dear Colleagues, > > The RIPE NCC is working on the implementation plan. It requires > changes to the core RIPE Database as well as several tools, such as > Webupdates and the LIR Portal, and then finally the Abuse Finder Tool. > Also some internal processes managed by the Registration and Customer > Services Departments need modifying to include a check that an > "abuse-c:" has been provided by a resource holder when requesting > services. > > The RIPE NCC expects to have the plan ready for publishing to the > community by mid November 2012. > I sent almost the exact same mail, as the questioner of this thread, in response to Emilio Madaios mail "[anti-abuse-wg] 2011-06 Proposal Accepted (Abuse Contact Management in the RIPE NCC Database)" asking for an ETA for the implementation. It makes me really angry to be ignored by people I pay to get service. It's not the first time I've been treated like this. Bengt G?rd?n Resilans AB Paying customer to RIPE From kranjbar at ripe.net Mon Nov 12 19:28:43 2012 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Mon, 12 Nov 2012 19:28:43 +0100 Subject: [anti-abuse-wg] abuse-c implementation schedule In-Reply-To: <50A135D3.8090300@bag.org> References: <5084FCAA.6040408@mutluit.com> <5084FFF7.2050003@hovland.cx> <50850240.3020600@powerweb.de> <50856D7C.90606@ripe.net> <50A135D3.8090300@bag.org> Message-ID: <1070A4FF-DAF5-489F-AF27-8BD5F45111EE@ripe.net> Hello Bengt, As announced before in this thread -as in the text you have quoted-, our plan will be announced by mid november. Our planning work is actually done and we are running it through all involved departments to be sure all involved parties can commit to the dates stated in the plan. The final announcement along with the detailed explanation and our proposed time line will be published in three days. Kind Regards, Kaveh Ranjbar, RIPE NCC Database Group Manager On Nov 12, 2012, at 6:45 PM, Bengt G?rd?n wrote: > 2012-10-22 17:59, Denis Walker skrev: >> Dear Colleagues, >> >> The RIPE NCC is working on the implementation plan. It requires changes to the core RIPE Database as well as several tools, such as Webupdates and the LIR Portal, and then finally the Abuse Finder Tool. Also some internal processes managed by the Registration and Customer Services Departments need modifying to include a check that an "abuse-c:" has been provided by a resource holder when requesting services. >> >> The RIPE NCC expects to have the plan ready for publishing to the community by mid November 2012. >> > > I sent almost the exact same mail, as the questioner of this thread, in response to Emilio Madaios mail "[anti-abuse-wg] 2011-06 Proposal Accepted (Abuse Contact Management in the RIPE NCC Database)" asking for an ETA for the implementation. It makes me really angry to be ignored by people I pay to get service. It's not the first time I've been treated like this. > > Bengt G?rd?n > Resilans AB > Paying customer to RIPE > From bengan at bag.org Wed Nov 14 13:47:35 2012 From: bengan at bag.org (=?UTF-8?B?QmVuZ3QgR8O2cmTDqW4=?=) Date: Wed, 14 Nov 2012 13:47:35 +0100 Subject: [anti-abuse-wg] abuse-c implementation schedule In-Reply-To: References: <5084FCAA.6040408@mutluit.com> <5084FFF7.2050003@hovland.cx> <50850240.3020600@powerweb.de> <50856D7C.90606@ripe.net> <20121112174541.2B77F33C38B@merlin.blacknight.ie> Message-ID: <50A392E7.4020402@bag.org> 2012-11-14 13:37, Michele Neylon :: Blacknight skrev: > This is a working group not RIPE NCC customer service .. I know that . . . . . . . . . . My first question was asked in the working group because it is demonstrably in the interest of the working group. If I can not get an proper answer here, I will of course take it up with the NCC, but it is good manners to complete the discussion where you started it. > > On 12 Nov 2012, at 17:45, Bengt G?rd?n wrote: > >> 2012-10-22 17:59, Denis Walker skrev: >>> Dear Colleagues, >>> >>> The RIPE NCC is working on the implementation plan. It requires changes to the core RIPE Database as well as several tools, such as Webupdates and the LIR Portal, and then finally the Abuse Finder Tool. Also some internal processes managed by the Registration and Customer Services Departments need modifying to include a check that an "abuse-c:" has been provided by a resource holder when requesting services. >>> >>> The RIPE NCC expects to have the plan ready for publishing to the community by mid November 2012. >>> >> I sent almost the exact same mail, as the questioner of this thread, in response to Emilio Madaios mail "[anti-abuse-wg] 2011-06 Proposal Accepted (Abuse Contact Management in the RIPE NCC Database)" asking for an ETA for the implementation. It makes me really angry to be ignored by people I pay to get service. It's not the first time I've been treated like this. >> >> Bengt G?rd?n >> Resilans AB >> Paying customer to RIPE >> > Mr Michele Neylon > Blacknight Solutions ? > Hosting & Domains > ICANN Accredited Registrar > http://www.blacknight.co > http://blog.blacknight.com/ > Intl. +353 (0) 59 9183072 > US: 213-233-1612 > Locall: 1850 929 929 > Facebook: http://fb.me/blacknight > Twitter: http://twitter.com/mneylon > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > From kranjbar at ripe.net Thu Nov 15 13:30:09 2012 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Thu, 15 Nov 2012 13:30:09 +0100 Subject: [anti-abuse-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database Message-ID: Dear Colleagues, The RIPE NCC's proposed implementation plan of RIPE policy 563 (policy proposal 2011-06) titled "Abuse Contact Management in the RIPE Database" is as follows: =========== Introduction =========== Abuse Contact Management in the RIPE Database (as defined in RIPE policy document 563) mandates the RIPE NCC to gather and publish abuse contact information for Internet resources provisioned by the RIPE NCC. =========== Approach =========== Abuse handling is generally a role within an organisation and the RIPE NCC is planning to model this relation in the RIPE Database. So the "abuse-c:" attribute will be available in the ORGANISATION object and should reference a ROLE object. When a ROLE object is referenced from an ORGANISATION object by the "abuse-c:" attribute, it must have an "abuse-mailbox:" attribute. All resources allocated or assigned by the RIPE NCC are required to have a reference to an ORGANISATION object in the RIPE Database. By adding a single "abuse-c:" attribute to their ORGANISATION object, a resource holder can quickly cover all their resources. All resources that are allocated or assigned by the RIPE NCC and which are subject to and compliant with current resource policies will then either directly reference an abuse contact or will inherit one from the parent resource. The detailed changes to RIPE Database objects and business rules, fine tuning, search options and facilities for quick data entry by RIPE NCC members using the LIR Portal are all described in an article on RIPE Labs: https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06 ============ Timeline ============ * Phase 0 - Q1 2013 The RIPE NCC will make internal changes to the RIPE Database and LIR Portal, this should be done by end of Q1 2013. * Phase 1 - Q2 and Q3 2013 The RIPE NCC will ask members to add "abuse-c:" to their member ORGANISATION object at least and will conduct a follow-up on that. RIPE NCC Members will be required to have abuse contact data for their resources when working with our Registration Services department. If a member has not added abuse-c:" to their ORGANISATION object by the end of this phase, the RIPE NCC will automatically add the member's published contact email address as the member's abuse contact. Members can edit this information any time through the LIR Portal. At the end of this phase, all PA allocations and their more specifics will have an abuse contact. * Phase 2 - Q4 2013 to Q3 2014 The RIPE NCC will ask AS Number and PI Resource holders to add abuse contact information to their ORGANISATION objects. If some resource holders have not added their abuse contact data by the end of this phase, the RIPE NCC will add the published abuse contact data for the responsible LIR to the ORGANISATION object listed in the resource. Any resource holder with access to the related object can always edit this information. At this point, ALL resources in the RIPE Database which are subject to and compliant with RIPE policies will have accessible abuse contact information. Please let us know if you like this proposal or have any feedback or ideas for improvement of this implementation proposal. Regards, Kaveh Ranjbar, RIPE NCC Database Group Manager -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane at time-travellers.org Thu Nov 15 16:38:37 2012 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 15 Nov 2012 16:38:37 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: References: Message-ID: <20121115163837.21cf97a2@shane-desktop> Kaveh, On Thursday, 2012-11-15 13:30:09 +0100, Kaveh Ranjbar wrote: > Abuse handling is generally a role within an organisation and the > RIPE NCC is planning to model this relation in the RIPE Database. So > the "abuse-c:" attribute will be available in the ORGANISATION object > and should reference a ROLE object. When a ROLE object is referenced > from an ORGANISATION object by the "abuse-c:" attribute, it must have > an "abuse-mailbox:" attribute. > > All resources allocated or assigned by the RIPE NCC are required to > have a reference to an ORGANISATION object in the RIPE Database. By > adding a single "abuse-c:" attribute to their ORGANISATION object, a > resource holder can quickly cover all their resources. All resources > that are allocated or assigned by the RIPE NCC and which are subject > to and compliant with current resource policies will then either > directly reference an abuse contact or will inherit one from the > parent resource. > > The detailed changes to RIPE Database objects and business rules, > fine tuning, search options and facilities for quick data entry by > RIPE NCC members using the LIR Portal are all described in an article > on RIPE Labs: > > https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06 I can't get to that article as the site is currently down, but basically I think you're describing something like this: +----------+ org: +--------------+ | resource +------->| ORGANISATION | +----------+ +--------+-----+ | | abuse-c: v -------- +------+ ( e-mail )<----------------+ ROLE | -------- abuse-mailbox: +------+ While it seems a bit complicated, the layers of indirection make sense, and if the Whois server follows the chains automatically then it should be workable. A maintainer only has to create a single mailbox and point to it once. A user gets the correct e-mail spit out somewhere logical in their Whois query. Cool. Looking forward to having this implemented so we can move on to the much scarier phase of abuse contact management. :) Cheers, -- Shane From fw at deneb.enyo.de Thu Nov 15 21:05:33 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 15 Nov 2012 21:05:33 +0100 Subject: [anti-abuse-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: (Kaveh Ranjbar's message of "Thu, 15 Nov 2012 13:30:09 +0100") References: Message-ID: <87wqxmd436.fsf@mid.deneb.enyo.de> * Kaveh Ranjbar: > Abuse handling is generally a role within an organisation and the > RIPE NCC is planning to model this relation in the RIPE Database. So > the "abuse-c:" attribute will be available in the ORGANISATION > object and should reference a ROLE object. When a ROLE object is > referenced from an ORGANISATION object by the "abuse-c:" attribute, > it must have an "abuse-mailbox:" attribute. Doesn't this invite mingling of allegedly privacy-relevant data and abuse contact information? From kranjbar at ripe.net Thu Nov 15 23:11:14 2012 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Thu, 15 Nov 2012 23:11:14 +0100 Subject: [anti-abuse-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <87wqxmd436.fsf@mid.deneb.enyo.de> References: <87wqxmd436.fsf@mid.deneb.enyo.de> Message-ID: On Nov 15, 2012, at 9:05 PM, Florian Weimer wrote: >> ... > > Doesn't this invite mingling of allegedly privacy-relevant data and > abuse contact information? Hello Florian, One of the reasons that it is only tied to the "role" object and not the "person" object is to avoid those issues. A role object is not designed to hold personal information, it is a representation of a unit in an organisation. The "abuse-mailbox:" attribute is also supposed to represent the generic email address of the contact point for the abuse handling entity within an organisation, not a real person. We will place clarifying notifications about this when users enter the data. None of the objects in the chain, "inetnum/inet6num/aut-num", "organisation" and "role" are provisioned as, or designed to be private data holders. Thank you for your comment, Kaveh. --- Kaveh Ranjbar, RIPE NCC Database Group Manager -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Fri Nov 16 07:06:42 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 16 Nov 2012 07:06:42 +0100 Subject: [anti-abuse-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: (Kaveh Ranjbar's message of "Thu, 15 Nov 2012 23:11:14 +0100") References: <87wqxmd436.fsf@mid.deneb.enyo.de> Message-ID: <87ip963wul.fsf@mid.deneb.enyo.de> * Kaveh Ranjbar: > One of the reasons that it is only tied to the "role" object and not > the "person" object is to avoid those issues. A role object is not > designed to hold personal information, it is a representation of a > unit in an organisation. The "abuse-mailbox:" attribute is also > supposed to represent the generic email address of the contact point > for the abuse handling entity within an organisation, not a real > person. We will place clarifying notifications about this when users > enter the data. > > None of the objects in the chain, "inetnum/inet6num/aut-num", > "organisation" and "role" are provisioned as, or designed to be > private data holders. Are you sure? After all, you anonymize these objects in the database dumps, citing data protection concerns: aut-num: AS3255 as-name: UARNET-AS descr: State Enterprise Scientific and Telecommunication Centre "Ukrainian Academic and Research Network" of the Institute for Condensed Matter Physics of the National Academy of Sc ience of Ukraine (UARNet) descr: EARN-Ukraine [...] admin-c: DUMY-RIPE tech-c: DUMY-RIPE [...] changed: [...] source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** inet6num: 2001:0658:021A::/48 netname: DE-TRMD-HACKETHAL-1 descr: IPv6 Markus Hackethal descr: Langenfeld country: DE admin-c: DUMY-RIPE tech-c: DUMY-RIPE status: ASSIGNED mnt-by: TRMD-MNT changed: [...] source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** inetnum: 80.16.151.184 - 80.16.151.191 netname: NETECONOMY-MG41731 descr: TELECOM ITALIA LAB SPA country: IT admin-c: DUMY-RIPE tech-c: DUMY-RIPE status: ASSIGNED PA [...] changed: [...] source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** organisation: ORG-NCC1-RIPE org-name: Dummy organisation name for ORG-NCC1-RIPE org-type: RIR address: Dummy address for ORG-NCC1-RIPE e-mail: unread at ripe.net mnt-ref: RIPE-NCC-RIS-MNT mnt-ref: RIPE-NCC-HM-MNT mnt-by: RIPE-NCC-HM-MNT changed: unread at ripe.net 20000101 source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** person: Placeholder Person Object address: RIPE Network Coordination Centre address: P.O. Box 10096 address: 1001 EB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: DUMY-RIPE mnt-by: RIPE-DBM-MNT remarks: ********************************************************** remarks: * This is a placeholder object to protect personal data. remarks: * To view the original object, please query the RIPE remarks: * Database at: remarks: * http://www.ripe.net/whois remarks: ********************************************************** changed: ripe-dbm at ripe.net 20090724 source: RIPE The latter is from the ripe.db.role.gz file. (Curiously, the "changed:" lines are left intact in the dump.) I worry that most LIRs put quite a bit of effort into updating the contact information, and then RIPE NCC decides to hide it because it's considered personal data, like all the other contact information currently in the database. From wiegert at telus.net Fri Nov 16 07:53:07 2012 From: wiegert at telus.net (Arnold) Date: Thu, 15 Nov 2012 22:53:07 -0800 Subject: [anti-abuse-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: References: <87wqxmd436.fsf@mid.deneb.enyo.de> Message-ID: <50A5E2D3.9000303@telus.net> On 15/11/2012 2:11 PM, Kaveh Ranjbar wrote: > > On Nov 15, 2012, at 9:05 PM, Florian Weimer > > wrote: >>> ... >> >> Doesn't this invite mingling of allegedly >> privacy-relevant data and >> abuse contact information? > > Hello Florian, > > One of the reasons that it is only tied to the "role" > object and not the "person" object is to avoid those > issues. A role object is not designed to hold personal > information, it is a representation of a unit in an > organisation. The "abuse-mailbox:" attribute is also > supposed to represent the generic email address of the > contact point for the abuse handling entity within an > organisation, not a real person. We will place clarifying > notifications about this when users enter the data. > > None of the objects in the chain, > "inetnum/inet6num/aut-num", "organisation" and "role" are > provisioned as, or designed to be private data holders. As a user of the RIPE database for reporting SPAM, I really don't need any of the associated personal information behind the 'abuse address'. I don't care about names, addresses etc. That part can and likely should stay hidden away without making the plain e-mail address any less useful. All that is really necessary to make that e-mail address effective and useful, that it actually is valid and mail to it will be acted on, promptly. Arnold > > Thank you for your comment, > Kaveh. > > --- > Kaveh Ranjbar, > RIPE NCC Database Group Manager -- Fight Spam - report it with wxSR 0.5 - ready for Vista & Win7 http://www.columbinehoney.net/wxSR.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: From vesely at tana.it Fri Nov 16 08:41:18 2012 From: vesely at tana.it (Alessandro Vesely) Date: Fri, 16 Nov 2012 08:41:18 +0100 Subject: [anti-abuse-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <87ip963wul.fsf@mid.deneb.enyo.de> References: <87wqxmd436.fsf@mid.deneb.enyo.de> <87ip963wul.fsf@mid.deneb.enyo.de> Message-ID: <50A5EE1E.3090308@tana.it> On Fri 16/Nov/2012 07:06:42 +0100 Florian Weimer wrote: > * Kaveh Ranjbar: > >> None of the objects in the chain, "inetnum/inet6num/aut-num", >> "organisation" and "role" are provisioned as, or designed to be >> private data holders. > > Are you sure? After all, you anonymize these objects in the database > dumps, citing data protection concerns: > [...] > admin-c: DUMY-RIPE > tech-c: DUMY-RIPE > > I worry that most LIRs put quite a bit of effort into updating the > contact information, and then RIPE NCC decides to hide it because it's > considered personal data, like all the other contact information > currently in the database. It may be necessary to contact a "person", sometimes. However, machines are not allowed to do that. I believe mechanisms better than the existing CAPTCHA are being considered, but that seems to be tied to a different implementation plan, as it is not entirely within RIPE. *Tools for searching* are mentioned in the Implementation Details page that Kaveh posted. Other pages are obsolete; for example, the Refinements to the RIPE Database Query API is of 23 Aug 2010, and has a broken link for the RIPE Database Web Services. The specification of RESTful web services for retrieving registration data involves all RIRs and most names registries, so it doesn't depend on RIPE only. Even so, I hope Kaveh will be able to keep us informed about those developments' timeline. From kranjbar at ripe.net Fri Nov 16 10:43:08 2012 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Fri, 16 Nov 2012 10:43:08 +0100 Subject: [anti-abuse-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <50A5EE1E.3090308@tana.it> References: <87wqxmd436.fsf@mid.deneb.enyo.de> <87ip963wul.fsf@mid.deneb.enyo.de> <50A5EE1E.3090308@tana.it> Message-ID: <64638ABD-5A01-4C30-85A0-2F28922AA67F@ripe.net> On Nov 16, 2012, at 8:41 AM, Alessandro Vesely wrote: > ... > The specification of RESTful web services for retrieving registration > data involves all RIRs and most names registries, so it doesn't depend > on RIPE only. Even so, I hope Kaveh will be able to keep us informed > about those developments' timeline. Hello Alessandro, The RIPE Database API documentation is located at: https://labs.ripe.net/ripe-database/database-api/api-documentation As mentioned in the documentation, we have a query and an update API. We maintain these APIs and there are already internal and external applications developed to use them. These APIs are specific to the RIPE Database and they cover almost all of the functionality provided by RIPE Database. There is also an IETF WEIRDS (http://datatracker.ietf.org/wg/weirds/charter/) effort. The drafts are close to becoming standards but they are not yet finalised and some of the basic functionality is still under review. When the standards are finalised, we will implement them as standard methods for accessing the RIPE Database but we will have to keep our own APIs because WEIRDS is focused on registry data and only covers a subset of RIPE Database queries. Any complex query, routing data query and updates to the database will still be handled by our own API. So to conclude, with implementation of "Abuse Contact Management" policy, we will implement all query functions in our own API and as soon as WEIRDS API is standard, we will provide the data through possible placeholders in the WEIRDS standards as well. I hope this addresses your concerns. Thank you for your comments. Kind Regards, Kaveh. --- Kaveh Ranjbar, RIPE NCC Database Group Manager -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at ripe.net Fri Nov 16 11:06:03 2012 From: denis at ripe.net (Denis Walker) Date: Fri, 16 Nov 2012 11:06:03 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <87ip963wul.fsf@mid.deneb.enyo.de> References: <87wqxmd436.fsf@mid.deneb.enyo.de> <87ip963wul.fsf@mid.deneb.enyo.de> Message-ID: <50A6100B.7080504@ripe.net> Dear Florien Thank you for your comments. You have touched on several issues here. Lets take them individually. Currently all data in the RIPE Database is publicly available, except password hashes. So any individual object can be queried and the full data returned. The RIPE Database does contain personal data and this data is also publicly available by querying the database, but with limits. To avoid data mining of this personal data, which is not required for any of the purposes of the database, the RIPE NCC does not allow bulk access to the personal data. The data examples you refer to are from the daily dump of the database. These have been "dummified" to remove personal data and references to personal data. The dummy PERSON and ORGANISATION objects you listed are place holders in the data dumps to maintain a consistent data set. The real objects and references are available if you query the RIPE Database within the acceptable use limits. None of the data that the LIRs maintain is hidden. But that part that is considered personal has some limits. The discussions around the abuse handling in the Anti Abuse Working Group have made it clear that this will not be personal data. So these ROLE objects will be available without the limits that personal data is subject to. They will also be available in the bulk data dumps. This is why we propose to allow an "abuse-c:" attribute to reference only a ROLE object and not a PERSON object. As Kaveh said, the ROLE object was not designed to, and should not, hold personal data. The tools the RIPE NCC will provide to facilitate abuse contact data entry will make it very clear that it will be available without limits and should not contain any personal data. The RIPE Database query service will also provision easy access to the abuse contact data related to individual resources without the need for users to drill down through individual data objects or hit any access limits. This should also help to avoid misuse of the personal data held in the RIPE Database. Regards, Denis Walker Business Analyst RIPE NCC Database Group On 16/11/2012 07:06, Florian Weimer wrote: > * Kaveh Ranjbar: > >> One of the reasons that it is only tied to the "role" object and not >> the "person" object is to avoid those issues. A role object is not >> designed to hold personal information, it is a representation of a >> unit in an organisation. The "abuse-mailbox:" attribute is also >> supposed to represent the generic email address of the contact point >> for the abuse handling entity within an organisation, not a real >> person. We will place clarifying notifications about this when users >> enter the data. >> >> None of the objects in the chain, "inetnum/inet6num/aut-num", >> "organisation" and "role" are provisioned as, or designed to be >> private data holders. > > Are you sure? After all, you anonymize these objects in the database > dumps, citing data protection concerns: > > aut-num: AS3255 > as-name: UARNET-AS > descr: State Enterprise Scientific and Telecommunication Centre "Ukrainian Academic and Research Network" of the Institute for Condensed Matter Physics of the National Academy of Sc > ience of Ukraine (UARNet) > descr: EARN-Ukraine > [...] > admin-c: DUMY-RIPE > tech-c: DUMY-RIPE > [...] > changed: [...] > source: RIPE > remarks: **************************** > remarks: * THIS OBJECT IS MODIFIED > remarks: * Please note that all data that is generally regarded as personal > remarks: * data has been removed from this object. > remarks: * To view the original object, please query the RIPE Database at: > remarks: * http://www.ripe.net/whois > remarks: **************************** > > inet6num: 2001:0658:021A::/48 > netname: DE-TRMD-HACKETHAL-1 > descr: IPv6 Markus Hackethal > descr: Langenfeld > country: DE > admin-c: DUMY-RIPE > tech-c: DUMY-RIPE > status: ASSIGNED > mnt-by: TRMD-MNT > changed: [...] > source: RIPE > remarks: **************************** > remarks: * THIS OBJECT IS MODIFIED > remarks: * Please note that all data that is generally regarded as personal > remarks: * data has been removed from this object. > remarks: * To view the original object, please query the RIPE Database at: > remarks: * http://www.ripe.net/whois > remarks: **************************** > > inetnum: 80.16.151.184 - 80.16.151.191 > netname: NETECONOMY-MG41731 > descr: TELECOM ITALIA LAB SPA > country: IT > admin-c: DUMY-RIPE > tech-c: DUMY-RIPE > status: ASSIGNED PA > [...] > changed: [...] > source: RIPE > remarks: **************************** > remarks: * THIS OBJECT IS MODIFIED > remarks: * Please note that all data that is generally regarded as personal > remarks: * data has been removed from this object. > remarks: * To view the original object, please query the RIPE Database at: > remarks: * http://www.ripe.net/whois > remarks: **************************** > > organisation: ORG-NCC1-RIPE > org-name: Dummy organisation name for ORG-NCC1-RIPE > org-type: RIR > address: Dummy address for ORG-NCC1-RIPE > e-mail: unread at ripe.net > mnt-ref: RIPE-NCC-RIS-MNT > mnt-ref: RIPE-NCC-HM-MNT > mnt-by: RIPE-NCC-HM-MNT > changed: unread at ripe.net 20000101 > source: RIPE > remarks: **************************** > remarks: * THIS OBJECT IS MODIFIED > remarks: * Please note that all data that is generally regarded as personal > remarks: * data has been removed from this object. > remarks: * To view the original object, please query the RIPE Database at: > remarks: * http://www.ripe.net/whois > remarks: **************************** > > person: Placeholder Person Object > address: RIPE Network Coordination Centre > address: P.O. Box 10096 > address: 1001 EB Amsterdam > address: The Netherlands > phone: +31 20 535 4444 > nic-hdl: DUMY-RIPE > mnt-by: RIPE-DBM-MNT > remarks: ********************************************************** > remarks: * This is a placeholder object to protect personal data. > remarks: * To view the original object, please query the RIPE > remarks: * Database at: > remarks: * http://www.ripe.net/whois > remarks: ********************************************************** > changed: ripe-dbm at ripe.net 20090724 > source: RIPE > > The latter is from the ripe.db.role.gz file. (Curiously, the > "changed:" lines are left intact in the dump.) > > I worry that most LIRs put quite a bit of effort into updating the > contact information, and then RIPE NCC decides to hide it because it's > considered personal data, like all the other contact information > currently in the database. > > From md at Linux.IT Fri Nov 16 17:03:07 2012 From: md at Linux.IT (Marco d'Itri) Date: Fri, 16 Nov 2012 17:03:07 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: References: Message-ID: <20121116160307.GA18018@bongo.bofh.it> On Nov 15, Kaveh Ranjbar wrote: > The RIPE NCC's proposed implementation plan of RIPE policy 563 (policy proposal 2011-06) titled "Abuse Contact Management in the RIPE Database" is as follows: Requiring that LIRs maintain a new and otherwise totally useless organization object for every customer who need a delegated abuse-c attribute is very inconvenient. At least unless that object can be simplified to contain only the abuse-c attribute and no other data. I believe that the original proposal (abuse-c attributes on hierarchical resources) would be much easier to deploy, even if it initially requires adding the abuse-c attribute to a (usually) small number of top-level inetnum objects. If LIRs with hundreds of directly-assigned resources are concerned about modifying them (are they?), then why not support both schemes? -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From fw at deneb.enyo.de Fri Nov 16 20:18:02 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 16 Nov 2012 20:18:02 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <50A6100B.7080504@ripe.net> (Denis Walker's message of "Fri, 16 Nov 2012 11:06:03 +0100") References: <87wqxmd436.fsf@mid.deneb.enyo.de> <87ip963wul.fsf@mid.deneb.enyo.de> <50A6100B.7080504@ripe.net> Message-ID: <87ehjte4r9.fsf@mid.deneb.enyo.de> * Denis Walker: > The discussions around the abuse handling in the Anti Abuse Working > Group have made it clear that this will not be personal data. So these > ROLE objects will be available without the limits that personal data > is subject to. They will also be available in the bulk data > dumps. This is why we propose to allow an "abuse-c:" attribute to > reference only a ROLE object and not a PERSON object. As Kaveh said, > the ROLE object was not designed to, and should not, hold personal > data. Does this mean that you will publish a ROLE object in the bulk dump once it is referenced from an abuse-c: field? Right now, you're redacting ROLE objects?but as Kaveh said, ROLE objects should not contain personal data, so there shouldn't be a reason for redacting them. That's where my confusion comes from, I guess. From kranjbar at ripe.net Mon Nov 19 10:38:27 2012 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Mon, 19 Nov 2012 10:38:27 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <20121116160307.GA18018@bongo.bofh.it> References: <20121116160307.GA18018@bongo.bofh.it> Message-ID: Hello Marco, Yes, in the data entry side a little bit more effort is required, but as we have mentioned at (https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06), there are two main reasons for that: a) This models the reality, in almost every case we know of, abuse handling is a role within an organisation. On he other hand attaching an email address to a resource is creating an arbitrary link. b) Operationally it is a lot more feasible for our members and users to enter data and more importantly to maintain this data over time if it is centralised in an entity modelled after their real work setup. All that said, we have also considered facilitating data entry. As we have mentioned we will provide additional tooling for data entry, so users can add their data easily. In the case you have mentioned, we are planning to provide a web based data entry tool which asks users for some basic required information and automatically prepares and creates both "ROLE" and "ORG" objects and then updates the internet resource in question. We just need to ask the user for the name of the entity, address, abuse contact email address and a maintainer and with that we can create all required objects and update the resource in question. We will also provide this through our update API for users who prefer to automatically add abuse contact information for their own customers. All the best, Kaveh. --- Kaveh Ranjbar, RIPE NCC Database Group Manager On Nov 16, 2012, at 5:03 PM, Marco d'Itri wrote: > On Nov 15, Kaveh Ranjbar wrote: > >> The RIPE NCC's proposed implementation plan of RIPE policy 563 (policy proposal 2011-06) titled "Abuse Contact Management in the RIPE Database" is as follows: > > Requiring that LIRs maintain a new and otherwise totally useless > organization object for every customer who need a delegated abuse-c > attribute is very inconvenient. > At least unless that object can be simplified to contain only the > abuse-c attribute and no other data. > ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From kranjbar at ripe.net Mon Nov 19 10:38:33 2012 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Mon, 19 Nov 2012 10:38:33 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <87ehjte4r9.fsf@mid.deneb.enyo.de> References: <87wqxmd436.fsf@mid.deneb.enyo.de> <87ip963wul.fsf@mid.deneb.enyo.de> <50A6100B.7080504@ripe.net> <87ehjte4r9.fsf@mid.deneb.enyo.de> Message-ID: <3D44A875-81A3-40F6-B5EA-A8AD83CE54F1@ripe.net> Hello Florian, You are right about "ROLE" objects in the bulk dump. They were designed to contain role information and they should hold non-personal data, but unfortunately over time this did not happen and that's why at the moment we have to hide personal data. Obviously we want to clean that up and as we have announced in RIPE 65 after we finish with reimplementing current software we will initiate and effort to clean up objects including "Role" objects with personal data, but that is a different story. However, as mentioned before, for roles referred from the "abuse-c:" we will put a notification during data entry. The notification will clearly state that this data will be published fully and will be accessible with no restrictions. With that in place, we don't have to "dummify" those objects anymore and "ROLE" objects with "abuse-mailbox:" attribute will be accessible with no restriction. Kind Regards, Kaveh. --- Kaveh Ranjbar, RIPE NCC Database Group Manager On Nov 16, 2012, at 8:18 PM, Florian Weimer wrote: > * Denis Walker: > >> ... This is why we propose to allow an "abuse-c:" attribute to >> reference only a ROLE object and not a PERSON object. As Kaveh said, >> the ROLE object was not designed to, and should not, hold personal >> data. > > Does this mean that you will publish a ROLE object in the bulk dump > once it is referenced from an abuse-c: field? > > Right now, you're redacting ROLE objects?but as Kaveh said, ROLE > objects should not contain personal data, so there shouldn't be a > reason for redacting them. That's where my confusion comes from, I > guess. > From fw at deneb.enyo.de Mon Nov 19 12:47:02 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 19 Nov 2012 12:47:02 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <3D44A875-81A3-40F6-B5EA-A8AD83CE54F1@ripe.net> (Kaveh Ranjbar's message of "Mon, 19 Nov 2012 10:38:33 +0100") References: <87wqxmd436.fsf@mid.deneb.enyo.de> <87ip963wul.fsf@mid.deneb.enyo.de> <50A6100B.7080504@ripe.net> <87ehjte4r9.fsf@mid.deneb.enyo.de> <3D44A875-81A3-40F6-B5EA-A8AD83CE54F1@ripe.net> Message-ID: <87obit4xxl.fsf@mid.deneb.enyo.de> * Kaveh Ranjbar: > However, as mentioned before, for roles referred from the "abuse-c:" > we will put a notification during data entry. The notification will > clearly state that this data will be published fully and will be > accessible with no restrictions. With that in place, we don't have > to "dummify" those objects anymore and "ROLE" objects with > "abuse-mailbox:" attribute will be accessible with no restriction. This is great news, thanks. From mir at ripe.net Fri Nov 30 10:00:04 2012 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 30 Nov 2012 10:00:04 +0100 Subject: [anti-abuse-wg] New on RIPE Labs: Link to Survey on Network Attack Detection and Mitigation Message-ID: <50B87594.7070101@ripe.net> Dear colleagues, Please note the link to a survey on network attack detection and mitigation provided by the Biometrics and Internet Security Research Group at the University Darmstadt: https://labs.ripe.net/Members/mirjam/survey-on-network-attack-detection-and-mitigation The survey is open until 4 December. Kind regards, Mirjam Kuehne RIPE NCC