Re: [anti-abuse-wg] [db-wg] Fw: NWI reviews: NWI-1 staying on top of abuse contact changes
On Thu, Sep 24, 2020 at 7:30 AM ripedenis--- via anti-abuse-wg wrote: [...] > Unless we go back to the drawing board and redesign the abuse contact system > (again) this is not going to be simplified any time soon. If the current design is not good enough and needs to be supplemented with tools to help registrants understand what has been registered, fixing the fundamental problem sounds reasonable to me. That said, I think it would be helpful if we could get a holistic sense of the complexity. Knowing the depth of hierarchies below allocations to LIRs and the number of hierarchies with multiple abuse contacts would provide some simple facts to inform the discussion. Is this possible? Kind regards, Leo Vegoda
[anti-abuse-wg] NWI issuing abuse contact changes, was reviews: NWI-1 staying on top of
On Wed 23/Sep/2020 01:45:26 +0200 ripedenis--- via anti-abuse-wg wrote: Hi Leo I was proposing a tool to help the registrant manage their data. If you want to find the abuse contact you just query the resource and the abuse contact is returned. I thought only ISPs had the right to manage their own abuse-c's. From the text below, I infer there are more ways to get the right data to the DB. For example, my ISP (Eutelia) went belly up between the change from abuse-mailbox to abuse-c. The one who took over (Clouditalia) never took care to point abuse-c to my abuse mailbox. Actually, they don't even reply to the email address currently pointed to (in CC). What are the extra methods which allow to carry out arrangements that the resource holder can overlook? Best Ale cheers denis co-chair DB-WG On Tuesday, 22 September 2020, 23:13:02 CEST, Leo Vegoda wrote: Hi Denis, On Tue, Sep 22, 2020 at 1:51 PM ripedenis--- via anti-abuse-wg mailto:anti-abuse-wg@ripe.net>> wrote: [...] Over time, with large hierarchies, we could end up with very complex arrangements with objects, attributes and values that have been overlooked and forgotten about. Even though they may have been forgotten about they are still 'active' and queries will return the most appropriate abuse contact details, even if it is the wrong contact. There is no simple query that will return the details of such a complex structure of abuse contact data in the RIPE Database. So there is no easy way for a resource holder to review or manage these abuse contacts. Although most resources will only ever have one abuse contact for the whole hierarchy, over several years we could end up with the kind of data swamp we had before we introduced the "abuse-c:" attribute for the larger networks. Any user could write their own script to do more specific queries, parse the returned objects and work out the abuse contact data structure for their resource. It would require detailed knowledge of the RIPE Database structure, the abuse contact rules and would involve multiple queries just to get the data, which you then have to visualise. My reason for this NWI-1 was to suggest the RIPE NCC creates a tool or RIPEstat widget that would take in a resource and map out the abuse contact details for the whole hierarchy including that resource. Would this be useful, is it necessary or a waste of time? Please discuss Should I understand this as a proposal for a tool that is used to keep the registrant informed about changes related to resources for which they are responsible, or a tool to help other network operators and users find the right place to send an abuse report? Many thanks, Leo
[anti-abuse-wg] [db-wg] Fw: NWI reviews: NWI-1 staying on top of abuse contact changes
Hi Lutz Good try but this script does not do it. Firstly, if you start with the allocation object it needs to be -rM in the first query. Then you are only looking for the "org:" attribute. The INET(6)NUM object may have an "abuse-c:" attribute in the object. It may have both in which case the local attribute overrides the "abuse-c:" in the referenced ORGANISATION object. Also to manage this feature it is not just about producing a list of abuse email addresses. It is knowing where these are referenced within a hierarchy and knowing which parts of the hierarchy are covered by which addresses. I agree that most resources will only have a single abuse contact referenced from their single ORGANISATION object. However, we were pushed hard by the community to allow "abuse-c:" to be added to the INET(6)NUM objects. I assume therefore that this feature has been used. So we already have a mix of abuse contacts referenced from both ORGANISATION and resource objects. When this was asked for the emphasis was on 'ease of use' to add these contacts. Probably no one gave much thought to how these contacts will be cleaned up when no longer relevant. It's most likely that someone will ask someone to remove it. Knowing human nature it is more likely some will just be forgotten about. If the contact is still there it is still active, but maybe no one is reading that email address any longer. I am not an operator so I don't know how many end user customers in large networks handle their own abuse reports. Or how many sub allocations handle abuse with their own customers handling abuse. So I don't know how complex this will get and maybe all operators already have good procedures in place to manage all this. That is why I am asking the question...is such a visualisation tool needed, useful or a waste of time? As an analyst, I can only see how complex this 'could' become over time. Unless we go back to the drawing board and redesign the abuse contact system (again) this is not going to be simplified any time soon. cheersdenis co-chair DB-WG On Thursday, 24 September 2020, 15:32:09 CEST, Lutz Donnerhacke via db-wg wrote: > > We need to take some action on these old NWIs. Either we move forward > with them or we cancel them. It is difficult to draw a consensus on 2 > comments. Can you please give us a couple of minutes of your time and > let us know if this NWI-1 is needed, useful or a waste of time. > > I share the view already expressed. If we need a tool, maybe the problem > is somewhere else. I support any proposal, that comes to the same result as the ripe whois database tool. It's not really hard to do correctly. #! /bin/sh getripe="whois -h whois.ripe.net --" $getripe -rL -T inetnum,inet6num "$1" | egrep '^org:' | while read ot ov; do $getripe -r -T organisation $ov | egrep '^abuse-c:' | while read at av; do $getripe -r $av | fgrep abuse-mailbox done done | tail -1 In order to fix the issue on the database side, it's necessary to prevent any occurrence of "abuse-mailbox" in all objects beside an newly created "abuse-contact" type, which is only allowed to referenced in the "abuse-c". See here for a corner case: https://lutz.donnerhacke.de/eng/Blog/Antispammers-and-Abuse-C
Re: [anti-abuse-wg] [db-wg] Fw: NWI reviews: NWI-1 staying on top of abuse contact changes
On Thu, Sep 24, 2020 at 12:30:06PM +, ripedenis--- via db-wg wrote: Denis, All, > We need to take some action on these old NWIs. Either we move forward with > them or we cancel them. It is difficult to draw a consensus on 2 comments. > Can you please give us a couple of minutes of your time and let us know if > this NWI-1 is needed, useful or a waste of time. I share the view already expressed. If we need a tool, maybe the problem is somewhere else. Best, Piotr -- Piotr Strzyżewski
[anti-abuse-wg] Fw: NWI reviews: NWI-1 staying on top of abuse contact changes
Colleagues We need to take some action on these old NWIs. Either we move forward with them or we cancel them. It is difficult to draw a consensus on 2 comments. Can you please give us a couple of minutes of your time and let us know if this NWI-1 is needed, useful or a waste of time. cheersdenis co-chair DB-WG - Forwarded message - From: ripedenis--- via anti-abuse-wg To: anti-abuse-wg@ripe.net Sent: Tuesday, 22 September 2020, 22:50:52 CESTSubject: [anti-abuse-wg] NWI reviews: NWI-1 staying on top of abuse contact changes Colleagues This is now a very old NWI that never got out of the starting blocks. I am posting this to the AA-WG as I think the discussion is more relevant to this community given the impact of not properly managing this data. https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005234.html Since I raised this point the world has moved on and the situation is now even more complex. The "abuse-c:" attribute can be added to:-the resource holders primary ORGANISATION object-any secondary ORGANISATION object referenced from any point in the address hierarchy-any resource object at any point in the address hierarchy-all, or any combination, of the above These (multiple) "abuse-c:" attributes can reference the same or multiple ROLE objects. These (multiple) ROLE objects can include "abuse-mailbox:" attributes referencing the same or multiple email addresses. Over time, with large hierarchies, we could end up with very complex arrangements with objects, attributes and values that have been overlooked and forgotten about. Even though they may have been forgotten about they are still 'active' and queries will return the most appropriate abuse contact details, even if it is the wrong contact. There is no simple query that will return the details of such a complex structure of abuse contact data in the RIPE Database. So there is no easy way for a resource holder to review or manage these abuse contacts. Although most resources will only ever have one abuse contact for the whole hierarchy, over several years we could end up with the kind of data swamp we had before we introduced the "abuse-c:" attribute for the larger networks. Any user could write their own script to do more specific queries, parse the returned objects and work out the abuse contact data structure for their resource. It would require detailed knowledge of the RIPE Database structure, the abuse contact rules and would involve multiple queries just to get the data, which you then have to visualise. My reason for this NWI-1 was to suggest the RIPE NCC creates a tool or RIPEstat widget that would take in a resource and map out the abuse contact details for the whole hierarchy including that resource. Would this be useful, is it necessary or a waste of time? Please discuss cheersdenis co-chair DB-WG
