Abuse Contact Information - Policy Proposal
Hello, this proposal was planned to be published end of May. But so many people asked me to publish it earlier and hopefully before RIPE-60 in Praha, so I will. This proposal is more or less a copy of our proposals for AfriNIC and APNIC. The APNIC proposal will be acknowledged today. The AfriNIC proposal will be discussed in Kigali end of this month. I will not be able to come to RIPE-60, but I hope that this proposal finds a little spot to be discussed in the Anti-Abuse Working Group Meeting. If you have questions, ideas or anything else that could help, let me know. Thanks, Tobias -- | Tobias Knecht | CEO | abusix UG (haftungsbeschraenkt) | tk@abusix.com | http://abusix.com | Postfach 210127 | 76151 Karlsruhe | Germany | --- | Register of Companies(Handelsregister): HRB 707959 | District of Court(Amtsgericht) Mannheim/Germany | Registered Office: Karlsruhe/Germany | CEO: Tobias Knecht
-----Original Message----- From: anti-abuse-wg-admin@ripe.net [mailto:anti-abuse-wg- admin@ripe.net] On Behalf Of Tobias Knecht Sent: Monday, May 03, 2010 9:56 AM To: anti-abuse-wg@ripe.net; Brian Nisbet; Richard Cox Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal
Hello,
this proposal was planned to be published end of May. But so many people asked me to publish it earlier and hopefully before RIPE-60 in Praha, so I will.
This proposal is more or less a copy of our proposals for AfriNIC and APNIC. The APNIC proposal will be acknowledged today. The AfriNIC proposal will be discussed in Kigali end of this month.
I will not be able to come to RIPE-60, but I hope that this proposal finds a little spot to be discussed in the Anti-Abuse Working Group Meeting.
If you have questions, ideas or anything else that could help, let me know.
Thanks,
Tobias
-- | Tobias Knecht | CEO | abusix UG (haftungsbeschraenkt) tk@abusix.com | | http://abusix.com Postfach 210127 | 76151 Karlsruhe | Germany | --- | Register of Companies(Handelsregister): HRB 707959 District of | Court(Amtsgericht) Mannheim/Germany Registered Office: | Karlsruhe/Germany | CEO: Tobias Knecht
Hello Tobias, This proposal sounds great! Regards, Mark
(Wearing my private citizen head)
4.3 Delete abuse-mailbox fields in all objects that do not define an IRT, and delete the trouble field everywhere in 2011.
This is a really bad idea, there is no guarantee those objects will allready be updated to link to an IRT object, nor is there a guarantee those objects will ever be updated to start linking to IRT. So you end up throwing away perfectly good data and end up with even more difficulties to find contact details. Marco
-----Original Message----- From: anti-abuse-wg-admin@ripe.net [mailto:anti-abuse-wg- admin@ripe.net] On Behalf Of Marco Hogewoning Sent: Monday, May 03, 2010 3:22 PM To: anti-abuse-wg@ripe.net Subject: Re: [anti-abuse-wg] Abuse Contact Information - Policy Proposal
(Wearing my private citizen head)
4.3 Delete abuse-mailbox fields in all objects that do not define an IRT, and delete the trouble field everywhere in 2011.
This is a really bad idea, there is no guarantee those objects will allready be updated to link to an IRT object, nor is there a guarantee those objects will ever be updated to start linking to IRT. So you end up throwing away perfectly good data and end up with even more difficulties to find contact details.
Is it acceptable for you if this is done when there is an IRT (and require it to have an IRT before 2013)? Mark
Is it acceptable for you if this is done when there is an IRT (and require it to have an IRT before 2013)?
I don't think you can 'require it to have an IRT by 2013', there are orphans and stale object, those will not magically will get an IRT attached. But we are getting into details where I think we first have to see where this proposal goes. I merely just pointed out there was a design oversight. Now concerning the proposal, IMHO it won't solve any of the problems. You get less data, but still no guarantee it's there or it's correct. This does not add anything compared to the current model. As a simple and alternative suggestion: Make the abuse-mailbox atrribute mandatory for inetnum and inet6num That was the original proposal at the start of the century when we introduced the abuse-mailbox stuff, by that time there was also a very lenghy discussion on IRT being an alternative. Please refer to the archives of the database working group for records on these discussions. Marco (as a private citizen)
Am 03.05.2010 17:23, schrieb Marco Hogewoning:
Is it acceptable for you if this is done when there is an IRT (and require it to have an IRT before 2013)?
I don't think you can 'require it to have an IRT by 2013', there are orphans and stale object, those will not magically will get an IRT attached. But we are getting into details where I think we first have to see where this proposal goes. I merely just pointed out there was a design oversight.
Just for clarification. This part came from the plan by APNIC to do something like an yearly frequent update request in combination with not having something like abuse-mailbox attributes or anything else activated in the whois database. The idea was to ask every member to update or accept their whois records once a year actively. Like .com registrars doing it already. I think this is a good idea as well, and this is brought into a proposal for APNIC very soon. I think we should agree on not accepting to create new or change abuse-mailbox attributes after a specific date. That is absolutely fine with me. If there will be a proposal where network owners will be forced to update their whois records yearly, we could put the cleanup into this proposal as well.
Now concerning the proposal, IMHO it won't solve any of the problems. You get less data, but still no guarantee it's there or it's correct. This does not add anything compared to the current model.
Exactly and this is the reason, why this proposal is a good one in my opinion, it's not adding anything, but it makes it far easier to understand the data. The point with this proposal is, that it should give a understandable definition how abuse contact information "have" to be published. This proposal shall show only a single place where abuse contact information can be found and not several that create confusion even within the RIPE members community. Another advantage is the fact that APNIC and probably AfriNIC will use the same way, which makes things much more easy on a global sight.
As a simple and alternative suggestion:
Make the abuse-mailbox atrribute mandatory for inetnum and inet6num
We discussed that as well, but there were several things that made it more complicated. 1.) there is no abuse-mailbox attribute within the inetnum and inet6num objects. That means this will need a major change in database. 2.) There is only the opportunity of publishing an email-address. Where do you want to publish further information? Phone numbers a personal contact address, ...? 3.) IRT-Objects exists, it's already there, The only thing that has to be changed is the fact that it has to be mandatory and contains a mandatory abuse-mailbox attribute.
That was the original proposal at the start of the century when we introduced the abuse-mailbox stuff, by that time there was also a very lenghy discussion on IRT being an alternative. Please refer to the archives of the database working group for records on these discussions.
I have read the really interesting discussion. Both ideas, IRT-Object and abuse-mailbox attribute are good. That's the reason why we are using both in our proposal. We just change the place where it should occur. Thank you for your feedback. Tobias
Tobias,
this proposal was planned to be published end of May. But so many people asked me to publish it earlier and hopefully before RIPE-60 in Praha, so I will.
This proposal is more or less a copy of our proposals for AfriNIC and APNIC. The APNIC proposal will be acknowledged today. The AfriNIC proposal will be discussed in Kigali end of this month.
I will not be able to come to RIPE-60, but I hope that this proposal finds a little spot to be discussed in the Anti-Abuse Working Group Meeting.
Thanks for this submission. I think that the best course of action is to discuss it on Thursday and get some additional feedback on the proposal. We'll then take what's been said on list, combine the two and we'll contact you with the plan of putting this into the RIPE policy development process. Regards, Brian.
Hi, On 3 May 2010, at 12:56, Tobias Knecht wrote:
this proposal was planned to be published end of May. But so many people asked me to publish it earlier and hopefully before RIPE-60 in Praha, so I will.
This proposal is more or less a copy of our proposals for AfriNIC and APNIC. The APNIC proposal will be acknowledged today. The AfriNIC proposal will be discussed in Kigali end of this month.
I will not be able to come to RIPE-60, but I hope that this proposal finds a little spot to be discussed in the Anti-Abuse Working Group Meeting.
On the proposal to "Institute a mandatory reference to an IRT object in inetnum, inet6num and aut-num objects." I note that there does not seem to currently be a technical need for this. According to the query reference manual: "Not every inet(6)num object needs to contain a reference to the irt object that applies to its range. A reference to an irt object does not apply only to the inet(6)num object that contains the reference. It also applies to all the inet(6)num objects that are 'more specific' to the one containing the reference. The irt reference only needs to be placed in the least specific encompassing object to apply to a whole hierarchy of objects. This makes it easier to apply and maintain." Also, I suspect that the requirement to add a reference to an IRT object when updating an inet(6)num will just result in fewer updates and an additional degradation in the quality of the registration and contact data provided. It is possible that I am wrong, so as a similar proposal has already been accepted by APNIC, perhaps this section of the proposal could be delayed until APNIC can present data showing the effect of this part of the policy on their data quality. Regards, Leo
Hello
Also, I suspect that the requirement to add a reference to an IRT object when updating an inet(6)num will just result in fewer updates and an additional degradation in the quality of the registration and contact data provided. It is possible that I am wrong, so as a similar proposal has already been accepted by APNIC, perhaps this section of the proposal could be delayed until APNIC can present data showing the effect of this part of the policy on their data quality.
Just a few words to this. I know that this proposal is just the first of a row of proposals that will lead to a more perfect system. ;-) For example. I start working with the APNIC policy office on the so called "frequent update request" proposal. This is a service APNIC wanted to start, but wanted to have a feedback from their members, that's why a proposal will be released. This "frequent update request" proposal shall find a way how APNIC (later AfriNIC and RIPE) can contact their members and requests perodically (yearly) updates or verifications on all objects. This proposal plans to solve problems like you and Marco Hogewoning mentioned. The idea for this proposal is not new. .com registrars are already having such mechanisms in place, and they work pretty well, as we have heard. At the end this first proposal shall just define a way where abuse contact information has to be in future and how this has to be handled with new ranges and with updates. The next proposal can find a way of requesting frequent updates. It's a step by step plan, but we should start somewhere. ;-) Thanks for your comments. Have all a nice RIPE-60 a good discussions tomorrow. Tobias
* Tobias Knecht:
4.1 Institute a mandatory reference to an IRT object in inetnum, inet6num and aut-num objects.
So it seems to me that one particular problem is that the abuse-mailbox data is not available in the bulk database dumps, and neither are the IRT objects. Wouldn't it be easier if RIPE created person/role object dumps, containing only the nic-hdl and the abuse-mailbox field? IRT object dumps would make a lot of sense, too. Historically, IRT objects had significant organizational overhead and have been subject to politics, so I'm not sure if they are the proper answer. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Hi,
4.1 Institute a mandatory reference to an IRT object in inetnum, inet6num and aut-num objects.
So it seems to me that one particular problem is that the abuse-mailbox data is not available in the bulk database dumps, and neither are the IRT objects.
I fully agree with the description of the problem. The biggest problem is, that RIPE is not telling their members which is the right way to publish abuse contact information and not telling them that they have to publish those information. And I disagree completely the opinion of not having any mandatory email addresses in the whois information. IMHO as long as an IP address can be abused, there must be a point of contact. The second problem is the query restriction. RIPE has more than 2 million inet(6)nums and it is absolutely impossible to query for the single IP addresses. Even with caching it is absolutely not possible. The idea to offer an abuse finder (http://labs.ripe.net/content/abuse-finder) is good and we will try that out soon.
Wouldn't it be easier if RIPE created person/role object dumps, containing only the nic-hdl and the abuse-mailbox field? IRT object dumps would make a lot of sense, too.
I think RIPE shuts down the Bulk Data Service because of Privacy issues. So that might not be the right way.
Historically, IRT objects had significant organizational overhead and have been subject to politics, so I'm not sure if they are the proper answer.
I know, but IMHO it does not make sense to create something new again. The mandatory IRT Object would solve almost all of those problems. Why is that? If you create an IRT Object with an abuse-mailbox attribute you can query the range or the single address with the "-b" flag which is not query restricted as far as RIPE told me. Use the Example of IRT-MCI-NL (whois -h whois.ripe.net IRT-MCI-NL) They have an abuse-mailbox attribute. So I can query: whois -h whois.ripe.net 193.67.0.0/16 -b whois -h whois.ripe.net 193.67.0.1 -b whois -h whois.ripe.net IRT-MCI-NL -b whois -h whois.ripe.net ASXXXX -b (would be possible I guess) and I always get back the abuse-mailbox attribute. That way everybody can build a caching system, that uses all the IRT Object found in the split files and connects them to the found abuse-mailbox attributes. And the second pro argument is, that the IRT Object allows to publish an e-mail attribute for personal communication. The query restriction forces us to send messages to the wrong contact, because we are not able to get the subdelegation contact because of the query restrictions. The arguments against are clear as well. So the decision must be done by RIPE and their members. APNIC did the decision and they will go online with the mandatory IRT Object in November. At the end I would be even happy if RIPE could agree on a Best Practice Paper which tells their members to use the IRT Object in the explained way to offer abuse contact information and stops creating of abuse-mailbox attributes in non IRT-Objects. With a Best Practice like that, everybody could easily reference on that without getting in discussions about the right way of doing it. Thanks, Tobias
* Tobias Knecht:
Wouldn't it be easier if RIPE created person/role object dumps, containing only the nic-hdl and the abuse-mailbox field? IRT object dumps would make a lot of sense, too.
I think RIPE shuts down the Bulk Data Service because of Privacy issues. So that might not be the right way.
What? Even for the inetnum objects? Can you provide a pointer for that, please?
whois -h whois.ripe.net IRT-MCI-NL -b
I would expect that query type to be subject to rate limits as well. And when every network block needs an IRT object, some people will likely script the creation of it, so you end up with less caching. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Am 14.07.2010 15:52, schrieb Florian Weimer:
* Tobias Knecht:
Wouldn't it be easier if RIPE created person/role object dumps, containing only the nic-hdl and the abuse-mailbox field? IRT object dumps would make a lot of sense, too.
I think RIPE shuts down the Bulk Data Service because of Privacy issues. So that might not be the right way.
What? Even for the inetnum objects? Can you provide a pointer for that, please?
http://ripe.net/ripe/maillists/archives/db-wg/2010/msg00063.html The inet(6)num Split Files contain all the Handles. But IRT Objects are defined as personal data, that way there is just a dummy split file.
whois -h whois.ripe.net IRT-MCI-NL -b
I would expect that query type to be subject to rate limits as well.
Database Documentation and testing tells me that there is no limit.
And when every network block needs an IRT object, some people will likely script the creation of it, so you end up with less caching.
How about making the IRT Object only mandatory for the direct allocations? That way we would have at least one abuse contact per IP. And the Netrange owner can decide if he wants to receive the complaints and if not he can create an irt for his subdelegations. Less caching does not hurt as long as the rate limits are not existing. Thanks, Tobias
Florian Weimer wrote:
* Tobias Knecht:
Wouldn't it be easier if RIPE created person/role object dumps, containing only the nic-hdl and the abuse-mailbox field? IRT object dumps would make a lot of sense, too.
I think RIPE shuts down the Bulk Data Service because of Privacy issues. So that might not be the right way.
What? Even for the inetnum objects? Can you provide a pointer for that, please?
Just to clarify this point, the RIPE NCC has no plans to shut down bulk access to operational data. The only restrictions are regarding personal and security data. There will be no bulk access to PERSON, ROLE, ORGANISATION or MNTNER objects. In other objects types NIC Handle references will also be removed from the bulk access data. Regards Denis Walker Business Analyst RIPE NCC Database Group
whois -h whois.ripe.net IRT-MCI-NL -b
I would expect that query type to be subject to rate limits as well. And when every network block needs an IRT object, some people will likely script the creation of it, so you end up with less caching.
* Denis Walker:
Just to clarify this point, the RIPE NCC has no plans to shut down bulk access to operational data. The only restrictions are regarding personal and security data. There will be no bulk access to PERSON, ROLE, ORGANISATION or MNTNER objects. In other objects types NIC Handle references will also be removed from the bulk access data.
NIC handles are operational data for many of us who need to contact operators to address issues we encounter and make the Internet a better place for everyone. I'm disappointed that RIPE NCC plans to take things into that direction. Was this project prompted by requests from the membership? At the very least, you could introduce an opt-in flag so that we can agree to have our data published in bulk form, so that we can benefit from others willing to help us to keep our networks clean. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Florian Weimer wrote:
* Denis Walker:
Just to clarify this point, the RIPE NCC has no plans to shut down bulk access to operational data. The only restrictions are regarding personal and security data. There will be no bulk access to PERSON, ROLE, ORGANISATION or MNTNER objects. In other objects types NIC Handle references will also be removed from the bulk access data.
NIC handles are operational data for many of us who need to contact operators to address issues we encounter and make the Internet a better place for everyone.
I'm disappointed that RIPE NCC plans to take things into that direction. Was this project prompted by requests from the membership?
At the very least, you could introduce an opt-in flag so that we can agree to have our data published in bulk form, so that we can benefit from others willing to help us to keep our networks clean.
Hi, we are voting for abuse data in bulk form too. We need nothing else but a simple dump from RIPEs abuse finder tool containing the netblock and the abuse email address. I personally dont think that this data could be declared as personal data, that needs to be protected by law. The netblock owner already decided explicitly to publish this (usually in remark fields or the optional abuse-email-field. If this is "too redical" I also recommend a simply flag in the LIR portal anybody could select. [x] publish abuse data in bulk form Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
Dear Florian, This is an issue that was raised by the lawyers to the RIPE Data Protection Task Force. After consideration by the Task Force a recommendation was put to the RIPE Database Working Group. There is a reference to this in the RIPE NCC presentation to the RIPE 59 meeting in Lisbon http://www.ripe.net/ripe/meetings/ripe-59/archives.php?day=thursday The bulk access daily split files still make available all the operational data. If, after processing that data, you need the personal data for a specific object you can query the RIPE Database for that object and return the personal data or just the references to it. With the current design of the RIPE Database there is no way to have any opt in methods for personal data. The RIPE NCC has no relationship with most of the people referenced by PERSON objects. RPSL does not provide any means of distinguishing between PERSON objects for network administrators and PERSON objects related to end user customer data. Nor does it provide any means to gather, verify and store such opt in approval. Regards Denis Walker Business Analyst RIPE NCC Database Group Florian Weimer wrote:
* Denis Walker:
Just to clarify this point, the RIPE NCC has no plans to shut down bulk access to operational data. The only restrictions are regarding personal and security data. There will be no bulk access to PERSON, ROLE, ORGANISATION or MNTNER objects. In other objects types NIC Handle references will also be removed from the bulk access data.
NIC handles are operational data for many of us who need to contact operators to address issues we encounter and make the Internet a better place for everyone.
I'm disappointed that RIPE NCC plans to take things into that direction. Was this project prompted by requests from the membership?
At the very least, you could introduce an opt-in flag so that we can agree to have our data published in bulk form, so that we can benefit from others willing to help us to keep our networks clean.
* Denis Walker:
The bulk access daily split files still make available all the operational data.
I don't think you can unilaterally declare what's operational and what's not. Does anyone else feel that the anti-abuse working group should ask RIPE NCC to work with its lawyers to make this data available?
If, after processing that data, you need the personal data for a specific object you can query the RIPE Database for that object and return the personal data or just the references to it.
By definition, role objects do not contain personal data. Corporations are not persons.
If, after processing that data, you need the personal data for a specific object you can query the RIPE Database for that object and return the personal data or just the references to it.
If you proceed in that direction, you will soon be forced to discontinue that service, too.
With the current design of the RIPE Database there is no way to have any opt in methods for personal data.
This is preposterous. As it stands, the whole thing is totally opt-in. There is no requirement whatsoever to associate inetnum objects with personal data. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Florian Weimer <fweimer@bfk.de> schrieb:
NIC handles are operational data for many of us who need to contact operators to address issues we encounter and make the Internet a better place for everyone.
I'm disappointed that RIPE NCC plans to take things into that direction.
I concur 100%.
Was this project prompted by requests from the membership?
A more-specific question would be, was this policy change authorised by any decision reached by means of the RIPE Policy Development Process? If so, can we please be given a reference to the documentation?
At the very least, you could introduce an opt-in flag so that we can agree to have our data published in bulk form, so that we can benefit from others willing to help us to keep our networks clean.
Contact information would only ever contain personal information if the person submitting the information chooses to utilise a personal mailbox rather than a role-account. I am reachable by email at abuse@btuser.net or richard.cox@btuser.net; only one of those constitutes personal data. It is my choice which I use in any given scenario. One size does not always fit all, so I'm not saying that because that works for me it should be imposed for everybody. What I am saying is that it provides a path forward. Perhaps the AAWG should at last dust off the policy-development process manuals and find out how we can DO something instead of just talking about it. It is just as valid for the AAWG to create a RIPE policy using that process, as it is for any of the other RIPE working groups to do so. My personal thinking goes something like this: Any entity which holds either an ASN, or an IP address range obtained DIRECTLY from RIPE or from an LIR, should be required by policy to provision an abuse mailbox; we should also recommend that such an abuse mailbox be in the form of a role account rather than an individual's mailbox. The same policy could also be applied to any sub-assignment greater than /25 (IPv4) or larger (and a similar figure should be chosen for IPv6 address blocks). That abuse mailbox should be included in all RIPE data elements, no matter how they are delivered. There is another strategy, which I have suggested before, which is that abuse (and possibly other contact) mailboxes would not be at the domain of the resource-holder, but in a special form "xxxxxxxxx@abuse.ripe.net" where "xxxxxxxxx" is an encrypted string pointing to the real mailbox and that string would actually change every (N) days, so that there would be no value in spammers harvesting such addresses. Mail to those addresses would be forwarded by the RIPE mailserver, with a re-written Return-Path etc so that a bounce would never go directly to the sender but instead come to the RIPE server where it would pass through a filter taking out the personal data. If mail to such an address did bounce in any quantity that could alert the RIPE analysts to the possibility that the resource was no longer in use, or that the resource holder no longer existed. That's a simplified description of a more-detailed spec which I worked out a while back, and something similar is currently in successful use by several domain registrars. So that proves it's not rocket-science! -- Richard Cox RDGC1-RIPE
On 23 Jul 2010, at 14:43, Richard Cox wrote:
My personal thinking goes something like this: Any entity which holds either an ASN, or an IP address range obtained DIRECTLY from RIPE or from an LIR, should be required by policy to provision an abuse mailbox; we should also recommend that such an abuse mailbox be in the form of a role account rather than an individual's mailbox. The same policy could also be applied to any sub-assignment greater than /25 (IPv4) or larger (and a similar figure should be chosen for IPv6 address blocks). That abuse mailbox should be included in all RIPE data elements, no matter how they are delivered.
That makes a lot of sense We encourage our clients to have their own abuse contacts, as it saves everyone time and energy. It would be good if there was some form of policy or even a suggest best practice ..
There is another strategy, which I have suggested before, which is that abuse (and possibly other contact) mailboxes would not be at the domain of the resource-holder, but in a special form "xxxxxxxxx@abuse.ripe.net" where "xxxxxxxxx" is an encrypted string pointing to the real mailbox and that string would actually change every (N) days, so that there would be no value in spammers harvesting such addresses. Mail to those addresses would be forwarded by the RIPE mailserver, with a re-written Return-Path etc so that a bounce would never go directly to the sender but instead come to the RIPE server where it would pass through a filter taking out the personal data. If mail to such an address did bounce in any quantity that could alert the RIPE analysts to the possibility that the resource was no longer in use, or that the resource holder no longer existed.
That's a simplified description of a more-detailed spec which I worked out a while back, and something similar is currently in successful use by several domain registrars. So that proves it's not rocket-science!
As a registrar I'd be interested in learning more !
-- Richard Cox RDGC1-RIPE
Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon PS: Check out our latest offers on domains & hosting: http://domainoffers.me/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
Hello together, why are we moving the problem of non existing abuse contact away from open access to bulk access. I would suggest the following. Anti-Abuse Working Group publishes a Best Practice Paper, which tells every RIPE member that the "ONE" and "ONLY" way for publishing abuse contact information is: Creating an IRT Object with an abuse-mailbox attribute. If there is such a paper, a lot of institutions will push this to their members as a best practice paper and they will have to follow. The next step is a policy proposal that does the following things: - Introduce the IRT Object into ASN Objects. - Make the abuse-mailbox attribute mandatory for the IRT Objects. - Make IRT Objects mandatory for directly by RIPE delegated Ranges. IMHO this will solve all the problems. Query is possible with the -b and you get for all IPs in the RIPE region at least one contact, that is in direct connection with RIPE. The Abuse Finder Tool (which is really cool) is able to give back an contactfor all IP addresses all the time. The query restriction problem is solved and Bulk Data service is not needed. Saves money, saves resources, save small institutions from not reporting abusive behavior because of to big barriers. The ISP/LIR/... can decide if he wants to receive all messages for his netranges and forward them to the right contact or if he offers his customers the possibility to create an own IRT Object. If the Object is wrong all messages go to the Top Contact again and he can check out why his customer is not offering the right contact information. I think this is all there, this is easy, it is not yet another big idea to solve all the problems and being disappointed if it is not working. Writing a Best Practice, making a abuse-mailbox attribute mandatory and making an IRT Object Mandatory should not waste resources at RIPE. Please give me just feedback to the Best Practice part. I think this should really happen and the next steps could be discussed in a policy process. Thanks, Tobias
On 7/23/10 4:32 PM, Tobias Knecht wrote:
Hello together,
why are we moving the problem of non existing abuse contact away from open access to bulk access.
I would suggest the following. [...]
Creating an IRT Object with an abuse-mailbox attribute.
- Introduce the IRT Object into ASN Objects. - Make the abuse-mailbox attribute mandatory for the IRT Objects. - Make IRT Objects mandatory for directly by RIPE delegated Ranges.
IMHO this will solve all the problems.
"All the problems" is maybe too optimistic, but at least we have something to start with. +1 I also like Richard's idea of xxxxxxxxx@abuse.ripe.net contact addresses: this will solve (part of) the problem of email-address exposure AND allow abuse address reachability monitoring. -- # Emanuele Balla # # # System & Network Engineer # Cell: +39 348 7747907 # # Spin s.r.l. - AS6734 # Phone: +39 040 9869090 # # Trieste # Email: balla@staff.spin.it #
Am 23.07.2010 16:57, schrieb Emanuele Balla:
On 7/23/10 4:32 PM, Tobias Knecht wrote:
Hello together,
why are we moving the problem of non existing abuse contact away from open access to bulk access.
I would suggest the following. [...]
Creating an IRT Object with an abuse-mailbox attribute.
- Introduce the IRT Object into ASN Objects. - Make the abuse-mailbox attribute mandatory for the IRT Objects. - Make IRT Objects mandatory for directly by RIPE delegated Ranges.
IMHO this will solve all the problems.
"All the problems" is maybe too optimistic, but at least we have something to start with.
+1
Okay, not all the problems, but it will be a good start and solve a lot of stuff which is discussed here for years.
I also like Richard's idea of xxxxxxxxx@abuse.ripe.net contact addresses: this will solve (part of) the problem of email-address exposure AND allow abuse address reachability monitoring.
I like the idea, but creating a single point of failure feels not right for me. There are huge ISPs which are having problems to receive all their incoming reports with really expensive high-end MTAs. The spammers will have the ability to harvest those addresses and attack the single point of failure. You will not even be able to filter the bad stuff because you do not know if it's really bad stuff or just a report with really bad stuff attached. Thanks, Tobias
On Friday 23 July 2010 17:57:21 Emanuele Balla wrote:
I also like Richard's idea of xxxxxxxxx@abuse.ripe.net contact addresses: this will solve (part of) the problem of email-address exposure AND allow abuse address reachability monitoring.
I am a bit skeptic about the creation of a single-point of failure that can be target of attacks with the gain being that the actual abuse addresses are not disclosed. This can cause more harm than good. Using public role accounts seems simpler. Kostas Zorbadelos
-- # Emanuele Balla # # # System & Network Engineer # Cell: +39 348 7747907 # # Spin s.r.l. - AS6734 # Phone: +39 040 9869090 # # Trieste # Email: balla@staff.spin.it #
On 23 Jul 2010, at 7:32, Tobias Knecht wrote: [...]
I would suggest the following.
Anti-Abuse Working Group publishes a Best Practice Paper, which tells every RIPE member that the "ONE" and "ONLY" way for publishing abuse contact information is:
Please see RFC 1925, section 2, point 10. That document may have been published on April Fool's Day but the statement is true, nonetheless. Solutions that require everyone else to change to for your convenience are unlikely to work the way you think they will. Regards, Leo Vegoda
On Fri, Jul 23, 2010 at 04:32:05PM +0200, Tobias Knecht wrote: Hi
I would suggest the following.
[cut]
The next step is a policy proposal that does the following things:
- Introduce the IRT Object into ASN Objects. - Make the abuse-mailbox attribute mandatory for the IRT Objects. - Make IRT Objects mandatory for directly by RIPE delegated Ranges.
So why are you not going to propose that under PDP? Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi,
The next step is a policy proposal that does the following things:
- Introduce the IRT Object into ASN Objects. - Make the abuse-mailbox attribute mandatory for the IRT Objects. - Make IRT Objects mandatory for directly by RIPE delegated Ranges.
So why are you not going to propose that under PDP?
Because I think a Best Practice Paper is easier to find consensus. But you are absolutely right there has to be a policy proposal in future. And there will be one. ;-) Thanks, Tobias
On Friday 23 July 2010 17:32:05 Tobias Knecht wrote: Tobias,
I would suggest the following.
Anti-Abuse Working Group publishes a Best Practice Paper, which tells every RIPE member that the "ONE" and "ONLY" way for publishing abuse contact information is:
Creating an IRT Object with an abuse-mailbox attribute.
If there is such a paper, a lot of institutions will push this to their members as a best practice paper and they will have to follow.
Best practice papers and documents should be I think one of the main purposes of an anti-abuse WG. I believe there is a lot of room for improvement in this area in this WG.
The next step is a policy proposal that does the following things:
- Introduce the IRT Object into ASN Objects. - Make the abuse-mailbox attribute mandatory for the IRT Objects. - Make IRT Objects mandatory for directly by RIPE delegated Ranges.
IMHO this will solve all the problems.
Query is possible with the -b and you get for all IPs in the RIPE region at least one contact, that is in direct connection with RIPE.
The Abuse Finder Tool (which is really cool) is able to give back an contactfor all IP addresses all the time.
The query restriction problem is solved and Bulk Data service is not needed. Saves money, saves resources, save small institutions from not reporting abusive behavior because of to big barriers.
The ISP/LIR/... can decide if he wants to receive all messages for his netranges and forward them to the right contact or if he offers his customers the possibility to create an own IRT Object. If the Object is wrong all messages go to the Top Contact again and he can check out why his customer is not offering the right contact information.
I think this is all there, this is easy, it is not yet another big idea to solve all the problems and being disappointed if it is not working. Writing a Best Practice, making a abuse-mailbox attribute mandatory and making an IRT Object Mandatory should not waste resources at RIPE.
Please give me just feedback to the Best Practice part. I think this should really happen and the next steps could be discussed in a policy process.
I am not sure sure if there are any "better" ways to achieve the result of having an abuse contact for all network ranges allocated in the RIPE region. There is however such a need which is not served now and your proposal of introducing one clear way to publish the information plus making it mandatory as a next step seems quite reasonable to me. Therefore I support your proposals. A general problem I find in this community, is that I see a lot of talk about issues and very little action. Clearly, abuse issues are not simple and there are no silver bullets, but I believe consensus on relatively small sub-areas can be reached and actions should be tried. This is a personal opinion of course and I would be interested to hear others on this subject. Do you have any schedule for the policy formation and submission?
Thanks,
Tobias
Regards Kostas PS: as a small personal experience, trying the abuse-finder tool of RIPE for spam arriving on my inbox, in most cases returns no abuse contact result. I guess this is a problem of data missing rather an error in the tool's logic.
Florian Weimer wrote:
* Tobias Knecht:
4.1 Institute a mandatory reference to an IRT object in inetnum, inet6num and aut-num objects.
So it seems to me that one particular problem is that the abuse-mailbox data is not available in the bulk database dumps, and neither are the IRT objects.
Wouldn't it be easier if RIPE created person/role object dumps, containing only the nic-hdl and the abuse-mailbox field? IRT object dumps would make a lot of sense, too.
Historically, IRT objects had significant organizational overhead and have been subject to politics, so I'm not sure if they are the proper answer.
Dear Florian Weimer Bulk access is always problematic where personal data is involved. You are correct that we do not provide dump files for PERSON and ROLE objects or for MNTNER objects which also have the possibility for "abuse-mailbox:" attributes. Within the next week or so we will be putting a new release of the software into production that creates these dump files. In this we have had to extend the restriction of bulk data access by removing NIC Handle references. This is because NIC Handles are regarded as personal data in Dutch law. So we would not be able to create a file as you suggested. But we will provide the dump file for IRT objects. It should also be remembered that IRT objects were introduced for a specific purpose that required additional administrative overhead. That purpose is still valid today and some of that overhead still applies to these objects. But it is not all bad news. We have an Abuse Finder Tool. This is still in a pre-production phase and is described on RIPE Labs: http://labs.ripe.net/content/updated-heuristics-abuse-finder-service This service will find "abuse-mailbox:" attributes and related IRT objects and "remarks:" attributes that 'look like' they contain a reference to an abuse handler for any specified Internet resource. This service currently works for RIPE and APNIC resources. To a limited extent it also works with AfriNIC's data, but they don't use IRT objects or "abuse-mailbox:" so it can only look for "remarks:". This service does not return any personal data other than abuse contacts. Therefore it is not subject to any access control limits. The tool provides 'on demand' access to abuse contacts as many times as you wish. This reduces, or in many cases eliminates, the need for access to bulk data. Regards Denis Walker Business Analyst RIPE NCC Database Group
Hello again,
But it is not all bad news. We have an Abuse Finder Tool. This is still in a pre-production phase and is described on RIPE Labs: http://labs.ripe.net/content/updated-heuristics-abuse-finder-service
This service will find "abuse-mailbox:" attributes and related IRT objects and "remarks:" attributes that 'look like' they contain a reference to an abuse handler for any specified Internet resource. This service currently works for RIPE and APNIC resources. To a limited extent it also works with AfriNIC's data, but they don't use IRT objects or "abuse-mailbox:" so it can only look for "remarks:".
This service does not return any personal data other than abuse contacts. Therefore it is not subject to any access control limits. The tool provides 'on demand' access to abuse contacts as many times as you wish. This reduces, or in many cases eliminates, the need for access to bulk data.
I really love it. This is a really good idea and this might help a lot. BUT: (sorry I have to ;-) I found out a few things: At the moment the XML Webservice is restricted. I was just trying to penetrate that service a little bit and it shut down after about 15 minutes of excessive usage. The service might be a little slow to use it without local caching. But I think that will change in future and with the "real" API. And last but not least the problem all RIRs have and such a great thing as the Abuse Finder will not solve the integrity and correctness (not accuracy). I have done a test, I was using all 4791 (/8 up to /16) ranges from the RIPE Database and shot them into the Abuse Finder. 2616 did have a results, which is around 54% 2175 did not have any result, which is around 45% That problem should be addresses as well. Probably with a Best Practice Paper. At the end there are some questions about data output. For example: 134.61.0.0/16 This range is giving back 2 different addresses. That is absolutely correct, but does it make sense? This will lead again to frustration of not knowing which is the right place and correct way to publish abuse related data. So I'm still a big fan of the IRT Object, because it is tailor made and solves all those problems. And probably once there will be a time, were it is not necessary to offer abuse-mailbox attributes for any other objects than the IRT and not necessary to use remark fields for abuse contact publishing and at that time it is not needed to do up to 150 queries for one request at the Abuse Finder. Thanks Tobias
participants (15)
-
Brian Nisbet -
Denis Walker -
Emanuele Balla -
Florian Weimer -
Frank Gadegast -
Kostas Zorbadelos -
Leo Vegoda -
Marco Hogewoning -
Mark Scholten -
Michele Neylon :: Blacknight -
Piotr Strzyzewski -
Richard Cox -
Stream Service -
Tobias Knecht -
Tobias Knecht