Re: [anti-abuse-wg] Reporting Fraud
Hello! Same problem here, it seems to be a general problem: FAILED instant-exchanger.com has neither MX nor A record set So no mail contact is possible. Spamhaus says to these IPs: http://www.spamhaus.org/sbl/sbl.lasso?query=SBL91148 i.e. 'Spam & cybercrime hosting: "InstantExchanger Ltd."' And it may be that the address in Belize also is bogus. (According to German anti-spam forums the real owners may be located in some spam groups in Germany.) So, isn't RIPE responsible for correct data in the WHOIS database? Best regards, - Karl-Josef Ziegler
Karl-Josef Ziegler <kjz@gmx.net> wrote:
So, isn't RIPE responsible for correct data in the WHOIS database?
I would say yes (assuming you mean the RIPE NCC - "we are RIPE") but I suspect the RIPE NCC would disclaim that responsibility. At least, the RIPE NCC should be held responsible when they are TOLD something is wrong. And even when they are told a record is wrong by the person named in it (which in one recent case was me) they still do not want to put it right. I'm about to ask the UK Information Commissioner to take action via the Dutch Data Protection (equivalent) office to enforce my rights under European law. The bottom line is that the real responsibility is at the start of the food chain ... the LIR that validated and submitted the original data. Which is why I think our first policy proposal should be that the name of the LIR (if any) that validated the original data, with a link to their contact details, must be included in the WHOIS response on every WHOIS lookup (port 43 or website, -b or no -b). -- Richard
On Wed, Sep 29, 2010 at 03:25:57PM +0000, Richard Cox wrote:
Which is why I think our first policy proposal should be that the name of the LIR (if any) that validated the original data, with a link to their contact details, must be included in the WHOIS response on every WHOIS lookup (port 43 or website, -b or no -b).
are you suggesting that the "mnt-by:" attribute should be made mandatory for person: objects? <http://www.ripe.net/db/support/update-reference-manual.html#1.2.14> -Peter
Peter Koch <pk@DENIC.DE> asked:
are you suggesting that the "mnt-by:" attribute should be made mandatory for person: objects?
No. I am suggesting that where an LIR represents to RIPE NCC that their customer is the party named on a request form, and that party meets the hardware etc requirement for allocation of RIPE resources, then the name of the LIR that made the representation should be included in the WHOIS output (for INETNUM and ASN objects). This would hopefully deter (the very small number of) LIRs that currently seem to be submitting resource requests that ultimately turn out to have been somewhat exaggerated. To give some background to this, there are two problem areas - Romania and Russia/Ukraine. Certain Romanian LIRs have for some time now been processing IP block requests from "customers" that turn out to not even be in the RIPE service region, and whose sole reason for requesting a block anywhere from a /22 to a /19 turns out to be one or two servers that want to be able to rapidly rotate their IP address(es) through such a large block in order that their activities (mostly spam) should go undetected. While RIPE does not have any policies that preclude the allocation of our scarce IPv4 resources for spammers, RIPE does have firm policies about the amount of hardware needed to justify allocation of IP blocks - policies which are being repeatedly ignored by said LIRs. In Russia/Ukraine we have a different problem: LIRs are requesting ASNs and IP space on behalf of criminal customers, whose sole objective in being allocated a /22 or similar is to mount one or two servers to be used as botnet Command and Controls, and as malware download sources - particularly by the gang currently running the Zeus trojans. Their method seems to be that by interposing one (but more commonly two) uncontactable ISPs between the server causing harm, and the rest of the internet, complaints will be sent first to the actual ISP, and later when those fail (because the ISPs don't really exist), to the upstream. It will take quite some time for complaints to be escalated as far as the third level. And in the case we documented earlier this morning, where the BGP Path points to ISPs that are _not_ carrying the criminal traffic, there will be even more confusion. -- Richard Cox
On Sep 29, 2010, at 5:07 PM, Richard Cox wrote:
Peter Koch <pk@DENIC.DE> asked:
are you suggesting that the "mnt-by:" attribute should be made mandatory for person: objects?
No. I am suggesting that where an LIR represents to RIPE NCC that their customer is the party named on a request form, and that party meets the hardware etc requirement for allocation of RIPE resources, then the name of the LIR that made the representation should be included in the WHOIS output (for INETNUM and ASN objects). This would hopefully deter (the very small number of) LIRs that currently seem to be submitting resource requests that ultimately turn out to have been somewhat exaggerated.
Can you expand on this? It sounds like you are referring to provider independent assignments to end users. I just looked through the inetnums for assignments made in the 91.192/10 range, which seems to currently be in use for this purpose and didn't see any missing a company name. It might be that I am not familiar with all the relevant company naming formats used in the RIPE NCC's service region but the inetnum objects were full of LLC, Joint Stock Company, BV, Sarl etc… Based on my limited analysis I don't understand the complaint. On the other hand, you might be referring to assignments that LIRs make to customers using space from their own allocations: ASSIGNED PA space. I downloaded the file containing all the inetnum objects (sans personally identifying contact information) from the RIPE NCC's FTP site and I found just over 3m inetnum objects in total and just under 3m PA assignments made by LIRs. I think the number of objects in that pool is sufficiently large that it is not practical to police the level of detail used in assignments made to customers when the LIR's contact information is published on the RIPE NCC's web site anyway. Regards, Leo
On Wed, Sep 29, 2010 at 03:25:57PM +0000, Richard Cox wrote:
The bottom line is that the real responsibility is at the start of the food chain ... the LIR that validated and submitted the original data. Which is why I think our first policy proposal should be that the name of the LIR (if any) that validated the original data, with a link to their contact details, must be included in the WHOIS response on every WHOIS lookup (port 43 or website, -b or no -b).
I was testing the waters about that during RIPE 59 Meeting (RIPE NCC Services Working Group session). You can find my short presentation here: http://www.ripe.net/ripe/meetings/ripe-59/presentations/strzyzewski-inet6num... According to my memory and to the minutes from the session there were mixed feelings about that. I was supposed to bring this topic back to the mailing list. Unfortunately (shame to me) I was extremally busy after meeting and totally forgot about that. Maybe this is the right time to make this a formal proposal and start a discussion? Regards, Piotr Strzyżewski -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> wrote:
According to my memory and to the minutes from the session there were mixed feelings about that.
But that would be the SERVICES working group, which people interested in Anti-Abuse would not normally attend (and most probably didn't).
I was supposed to bring this topic back to the mailing list.
But WHICH mailing list? This list, or the services WG list ?
Unfortunately (shame to me) I was extremally busy after meeting and totally forgot about that. Maybe this is the right time to make this a formal proposal and start a discussion?
I would certainly say it is the right time. The important question is, which is the right place? (I'm biased: I would say it should be here!) -- Richard
On Thu, Sep 30, 2010 at 10:50:52AM +0000, Richard Cox wrote:
Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> wrote:
According to my memory and to the minutes from the session there were mixed feelings about that.
But that would be the SERVICES working group, which people interested in Anti-Abuse would not normally attend (and most probably didn't).
I could be wrong now, but I recall that I have talked about that (which WG should I present this topic to) with Gert Doering, Wilfried Woeber and Bijal Sanghani during the RIPE 59 Meeting and they pointed out RIPE NCC Services as the right place to begin the discussion.
I was supposed to bring this topic back to the mailing list.
But WHICH mailing list? This list, or the services WG list ?
Services.
Unfortunately (shame to me) I was extremally busy after meeting and totally forgot about that. Maybe this is the right time to make this a formal proposal and start a discussion?
I would certainly say it is the right time. The important question is, which is the right place? (I'm biased: I would say it should be here!)
Ok, so I promise to make this policy proposal by the beggining of the next week. We can start discussion here and then notify the others (since I believe this equally could interest at least AP, DB and Services WGs). Best regards, Piotr Strzyżewski -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hello, as promised I updated the policy proposals from APNIC and send it to this list and beginning of next week I will start the RIPE NCC Policy Proposal Process. Please review and give feedback. And yes, there are still some things in the proposal, where some people might not like. I just would like to see the opinion of the RIPE members first and not only from people who have read my proposals on other mailinglists before. Thank you very much. Tobias ________________________________________________________________________ Frequent Update Reminder ________________________________________________________________________ Author: Tobias Knecht <tk@abusix.com> CEO - abusix.org Co-Chair AK-EMAIL eco e.V. Version: 1 Date: August 11th 2010 RIPE WGs: AA + DB Proposal Type: new Policy Term: permanent 1. Introduction ---------------- This is a proposal for RIPE to regularly contact all RIPE current account holders with resources in the RIPE Whois Database to ask them to actively check that all their details in whois are up to date. To actively check details, the object owner has to log into the LIR Portal and acknowledge the accuracy of data in their object(s) or update all existing objects if needed. The update date will be shown in the "changed" attribute of every single object. 2. Summary of current problem ------------------------------ Whois database data accuracy has been a big issue for years now. There have been several approaches to get better data accuracy within whois information all over the world. There are two main reasons for data inaccuracy in whois: a) Wrong data is published to camouflage illegal actions. b) Wrong data is published because object owners forget to update the whois information as changes occur within their organization (staff changes, etc.) A secondary problem is data incompleteness: - Sometimes, there are changes to the structure of whois data, such as additional mandatory objects or attributes (for example, the IRT object). Object owners usually do not immediately make these changes to the objects they are responsible for. So there is always data missing in the whois database. 3. Situation in other RIRs --------------------------- ARIN conducts an annual POC (point of contact) validation process: https://www.arin.net/policy/nrpm.html#three6 APNIC is still discussing about a similar approach at the moment: http://www.apnic.net/__data/assets/file/0006/22857/prop-084-v002.txt If the current APNIC and RIPE proposals are successful, the author plans to submit a similar proposal for AfriNIC, LACNIC regions. 4. Details of the proposal --------------------------- It is proposed that RIPE: 4.1 Send an update notification for all existing objects to the corresponding responsible organization once every X months. This notification will explain that object owners must log in the LIR Portal and verify all objects they are responsible for. The objects covered by this proposal are: - inetnum - inet6num - aut-num - person - role - org - irt Object owners must actively click and acknowledge the correctness of the objects they are responsible for. - If an object needs updating, or a new object needs to be added (for example, an IRT object), the owner can do this via the LIR Portal. - If a new object or attribute is made mandatory via another RIPE policy, then the responsible organization will be required to make this update, if not already made, at the time of notification. Even if the owner only verifies existing data and has not made any changes, the "changed" attribute in the whois database objects will include the date the owner verified the object. This will give users of whois an idea on how recently the object owner verified the accuracy of the data. 4.2 Send update notifications to responsible organizations at times shorter than the regular period described in section 4.1 if RIPE is made aware that the organization's object contain invalid information. 4.3 RIPE will offer web form which gives whois users the ability to report invalid whois objects. See APNIC webform as example: http://www.apnic.net/invalidcontact A link to the webform shall be linked in all whois output for reporting invalid contact information. 4.4 Handle non-responsive object owners in the following way: - Owners will have 60 days from the time of initial message from APNIC to confirm that their objects are up to date. - If the object owner does not respond to the initial message, reminder emails will be sent 10, 30 and 50 days after the original email. - After the 60-day period has passed, if the object owner has not verified their object details, APNIC will add the ranges of resources maintained by the non-responsive object owner to the publicly available list of resources described in 4.5.1 below. 4.5 Maintain two publicly available lists: 4.5.1 Resources associated with non-responsive object owners - This list would include resources associated with object owners who have not responded to RIPE's requests as described in section 4.4 above. 4.5.2 Resources associated with known invalid contact details - This list would include resources that have been reported to contain invalid contact details. - It is left to the discretion of the RIPE Secretariat whether to include an explicit remark in the corresponding database objects to show that the information in the objects is invalid. 5. Advantages and disadvantages of the proposal ------------------------------------------------ 5.1 Advantages - A frequent reminder and the need to actively verify will solve the problem of forgetting to update objects. - All objects will follow the latest requirements for registration in the RIPE Whois Database. For example if there is a mandatory field added within X months every object will be updated. - More people will use the LIR Portal. 5.2 Disadvantages - No disadvantages are foreseen. 6. Effect on RIPE members --------------------------- Members have to update or verify their objects once every X months.
On Thu, Sep 30, 2010 at 11:48:48AM +0200, Tobias Knecht wrote: Hi Just few comments.
a) Wrong data is published to camouflage illegal actions.
b) Wrong data is published because object owners forget to update
I do think that better words are: - outdated instead of wrong, - maintainers or owners instead of owners (this also applies in few other places in the text).
The objects covered by this proposal are:
- inetnum - inet6num - aut-num - person - role - org
organisation not org
It is proposed that RIPE:
RIPE NCC not RIPE (this also applies in few other places in the text).
- If an object needs updating, or a new object needs to be added (for example, an IRT object), the owner can do this via the LIR Portal.
There are few other methods of adding/updating objects. Maybe this text should look like this: - Any updates or additions of new objects (for whatever reason) should be done if necessary.
Even if the owner only verifies existing data and has not made any changes, the "changed" attribute in the whois database objects will include the date the owner verified the object. This will give users of whois an idea on how recently the object owner verified the accuracy of the data.
Maybe new attribute should be considered? Right now anyone can create any number of changed: lines with virtually any dates.
4.4 Handle non-responsive object owners in the following way:
- Owners will have 60 days from the time of initial message from APNIC to confirm that their objects are up to date.
RIPE NCC ;-) (this also applies in few other places in the text).
- If the object owner does not respond to the initial message, reminder emails will be sent 10, 30 and 50 days after the original email.
- After the 60-day period has passed, if the object owner has not verified their object details, APNIC will add the ranges of resources maintained by the non-responsive object owner to the publicly available list of resources described in 4.5.1 below.
I don't imagine clicking more than hundreds of thousands times to confirm validation of whois objects, every X months, during 60 days. Those numbers will apply to some LIRs. We should provide some API for that.
4.5.2 Resources associated with known invalid contact details
- This list would include resources that have been reported to contain invalid contact details.
So, this list will be filled automatically after any report?
5.2 Disadvantages
- No disadvantages are foreseen.
At least one - a lot of work to do for LIR staff. ;-) Regards, Piotr Strzyżewski -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On 09/30/10 11:48, Tobias Knecht wrote:
Please review and give feedback. And yes, there are still some things in the proposal, where some people might not like. I just would like to see the opinion of the RIPE members first and not only from people who have read my proposals on other mailinglists before.
Hi Tobias. Sure thing.
Object owners must actively click and acknowledge the correctness of the objects they are responsible for.
I am not going to click on 500 emails and type "yes I concur" every X months. If I was forced I would create a robot that did it for me and also sell this as a proxy service to people that were fed up about it. Since I love money, please believe me when I say this: I really support your proposal. I really do! FYI: I already receive hundreds of emails from TLD providers about the same. These go straight to my spamfolder though. Cheers, J
In message <4CA477D3.50803@hovland.cx>, =?ISO-8859-15?Q?J=F8rgen_Hovland?= <jorgen@hovland.cx> wrote:
I am not going to click on 500 emails and type "yes I concur" every X months.
I'm just an ignorant hick from the other side of the pond. Please take pity on me and enlighten me. You are the Responsible Party for 500 separate and different IP allocations? Really??
On Thu, Sep 30, 2010 at 08:05:40PM -0700, Ronald F. Guilmette wrote:
In message <4CA477D3.50803@hovland.cx>, =?ISO-8859-15?Q?J=F8rgen_Hovland?= <jorgen@hovland.cx> wrote:
I am not going to click on 500 emails and type "yes I concur" every X months.
I'm just an ignorant hick from the other side of the pond. Please take pity on me and enlighten me.
You are the Responsible Party for 500 separate and different IP allocations?
Really??
Simple whois question about Polish Telecom's inetnum objects without person/role references: $ whois -T inetnum -r -i mnt-by TPNET |grep ^inetnum: |wc -l 201157 Best regards, Piotr Strzyżewski -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hello,
In message <4CA477D3.50803@hovland.cx>, =?ISO-8859-15?Q?J=F8rgen_Hovland?= <jorgen@hovland.cx> wrote:
I am not going to click on 500 emails and type "yes I concur" every X months.
I'm just an ignorant hick from the other side of the pond. Please take pity on me and enlighten me.
You are the Responsible Party for 500 separate and different IP allocations?
Really??
Simple whois question about Polish Telecom's inetnum objects without person/role references:
$ whois -T inetnum -r -i mnt-by TPNET |grep ^inetnum: |wc -l 201157
How about keeping the proposal as it is and just change from updating _all_ objects to just update the direct from RIPE allocated inet(6)num autnums. That way there should be at least one accurate contact for every ip-address in the RIPE region. If subdelegations are wrong, there will be still a request for correcting the data and the inet(6)num, aut-num will still appear on the lists, but the pressure is smaller and it would help. For example if the contact of a subdelegated range is wrong the abuse reports could be send to the delegation above, and above and so on. How does that sound? Thanks, Tobias
On Fri, Oct 01, 2010 at 08:57:11AM +0200, Tobias Knecht wrote: Hi
Simple whois question about Polish Telecom's inetnum objects without person/role references:
$ whois -T inetnum -r -i mnt-by TPNET |grep ^inetnum: |wc -l 201157
How about keeping the proposal as it is and just change from updating _all_ objects to just update the direct from RIPE allocated inet(6)num autnums.
That way there should be at least one accurate contact for every ip-address in the RIPE region. If subdelegations are wrong, there will be still a request for correcting the data and the inet(6)num, aut-num will still appear on the lists, but the pressure is smaller and it would help.
For example if the contact of a subdelegated range is wrong the abuse reports could be send to the delegation above, and above and so on.
How does that sound?
Correct me if I am wrong, but this is more or less the same what RIPE NCC is doing right now. Allocations are maintained by RIPE-NCC-HM-MNT, organisation objects with org-type field set to LIR are maintained by RIPE-NCC-HM-MNT. Those objects are filled with date coming from both internal database (used also for accounting purposes) and LIR portal. Every year LIRs are paying their invoices, which proves that both email and snail mail addresses provided as billing contacts are working. Best regards, Piotr Strzyżewski -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi Piotr,
Correct me if I am wrong, but this is more or less the same what RIPE NCC is doing right now. Allocations are maintained by RIPE-NCC-HM-MNT, organisation objects with org-type field set to LIR are maintained by RIPE-NCC-HM-MNT. Those objects are filled with date coming from both internal database (used also for accounting purposes) and LIR portal. Every year LIRs are paying their invoices, which proves that both email and snail mail addresses provided as billing contacts are working.
But it does not mean that admin-c, tech-c, IRT and all other objects are accurate. For example: We are at the moment just using the delegated information, which is not good but we are working on. Different subject. We see loads of abuse-mailbox attributes not being correct, or giving back a "mailbox full" or "550 - address not existing" We receive at least every second month an email where somebody is asking us why we are sending reports to them, because they are not working for this company for years, but the objects are still linked to the inet(6)num or aut-nums. One of those guys (74 years old) now sued his old company, he worked for until 2002, because they didn't change the whois information on his request for over a year and he was getting frustrated. These are the things that should be faced with this proposal. Another idea could be, that once a year an email is sent to the email address in the person object and person it self has to acknowledge that the information is accurate and so on. If those mails bounce or the customer is not replying within a few days the issue will be forwarded to the maintainer of the netrange. By thinking about this approach I think this could at least work pretty good as well. And the best would be a combination. Sending update request for inet(6)num, aut-num, IRT, ..., Organization Objects to the maintainers and send frequent requests for person objects to the person it self. Sounds more reasonable? Thanks, Tobias
On Fri, Oct 01, 2010 at 09:42:02AM +0200, Tobias Knecht wrote: Hi Tobias
Correct me if I am wrong, but this is more or less the same what RIPE NCC is doing right now. Allocations are maintained by RIPE-NCC-HM-MNT, organisation objects with org-type field set to LIR are maintained by RIPE-NCC-HM-MNT. Those objects are filled with date coming from both internal database (used also for accounting purposes) and LIR portal. Every year LIRs are paying their invoices, which proves that both email and snail mail addresses provided as billing contacts are working.
But it does not mean that admin-c, tech-c, IRT and all other objects are accurate.
That's true.
Another idea could be, that once a year an email is sent to the email address in the person object and person it self has to acknowledge that the information is accurate and so on. If those mails bounce or the customer is not replying within a few days the issue will be forwarded to the maintainer of the netrange.
By thinking about this approach I think this could at least work pretty good as well.
And the best would be a combination. Sending update request for inet(6)num, aut-num, IRT, ..., Organization Objects to the maintainers and send frequent requests for person objects to the person it self.
Sounds more reasonable?
A bit more. ;-) IMHO good API to this acknowledge mechanism will be more then necessary. Regards, Piotr Strzyżewski -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi, On Fri, Oct 01, 2010 at 08:57:11AM +0200, Tobias Knecht wrote:
How about keeping the proposal as it is and just change from updating _all_ objects to just update the direct from RIPE allocated inet(6)num autnums.
This makes more sense to me. We have about 7 allocated inet(6)num objects (and their contacts are OK), and about 500+ assigned inet(6)num objects - most of which are ok, but sometimes customer mail addresses change and we're not told, so some of them will always be broken. Our customer support people know how to reach the customer, so if an abuse complaint hits our support desk, we *will* contact the customers (and if we're told that the inetnum: data is wrong, we'll fix that, of course) - so I think we're in pretty good shape, and having to click 500x "yes, ok" once a year is overdoing things a bit... Gert Doering -- LIR contact for de.space -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Fri, Oct 01, 2010 at 08:47:09AM +0200, Piotr Strzyzewski wrote:
On Thu, Sep 30, 2010 at 08:05:40PM -0700, Ronald F. Guilmette wrote:
In message <4CA477D3.50803@hovland.cx>, =?ISO-8859-15?Q?J=F8rgen_Hovland?= <jorgen@hovland.cx> wrote:
I am not going to click on 500 emails and type "yes I concur" every X months.
I'm just an ignorant hick from the other side of the pond. Please take pity on me and enlighten me.
You are the Responsible Party for 500 separate and different IP allocations?
Really??
Simple whois question about Polish Telecom's inetnum objects without person/role references:
$ whois -T inetnum -r -i mnt-by TPNET |grep ^inetnum: |wc -l 201157
Just to excuse myself and clarify one thing:
From the original proposal: "4.1 Send an update notification for all existing objects to the corresponding responsible organization once every X months."
Your question was about allocations. But the proposal is about both assignments and allocations, so my answer was more general. Best regards, Piotr Strzyżewski -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hello, I updated the 2 policy proposals in the way it was suggested by people on this list and sent it to the RIPE Secretary to start the official part. Please see latest version attached here. Thanks for all suggestions and ideas, If you still have some ideas, let me and all others know. Thanks, Tobias
Hello, as promised I updated the policy proposals from APNIC and send it to this list and beginning of next week I will start the RIPE NCC Policy Proposal Process. Please review and give feedback. And yes, there are still some things in the proposal, where some people might not like. I just would like to see the opinion of the RIPE members first and not only from people who have read my proposals on other mailinglists before. Thank you very much. Tobias ________________________________________________________________________ Abuse contact information ________________________________________________________________________ Author: Tobias Knecht <tk@abusix.com> abusix.org Version: 1 Date: 3 May 2010 RIPE WGs: anti-abuse (database) Proposal Type: new Policy Term: permanent 1. Introduction ---------------- This is a proposal to introduce a mandatory reference to IRT objects in the inetnum, inet6num and aut-num objects in the RIPE Whois Database. It provides a more accurate and efficient way for abuse reports to reach the correct network contact and helps reporting institutions to find the correct abuse contact information more easily. 2. Summary of current problem ------------------------------ Network owners increasingly operate dedicated abuse handling departments, distinct from the basic operations department. More and more network owners and other institutions are also starting to exchange data about abusive behavior with each other, to more quickly allow networks to identify internal abuse, external abuse, and other security problems. Currently within the RIPE region, the biggest problem for network operators is to know the best place to publish abuse contact information. (IRT, abuse-mailbox, remark-fields, and in addition to that, in which object they should publish them?) On the other hand abuse reporting parties having a huge problem by finding a correct abuse contact in the variety of possibilities. Since there is a specialized object (IRT) for abuse contacts, this should be mandatory, to stop the uncontrolled growth. 3. Situation in other RIRs --------------------------- AfriNIC: AfriNIC is also discussing about a similar policy proposal. [1] APNIC: This policy was acknowledged by the APNIC members in Kuala Lumpur in March 2010.[2] Implementation will be finished in November 2010. ARIN: An abuse-POC exists for Organizational ID identifiers.[3] LACNIC: An abuse-c exists for aut-num, inetnum and inet6num objects.[4] 4. Details of the proposal --------------------------- It is proposed that RIPE: 4.1 Institute a mandatory reference to an IRT object in inetnum, inet6num and aut-num objects. In terms of implementing a mandatory IRT reference, it is suggested that this be part of two, established actions: - The next time an organization attempts to update an existing inetnum, inet6num or aut-num object - When new inetnum, inet6num or aut-num objects are added to the database 4.2 Have a mandatory abuse-mailbox field in the IRT object. 4.3 Delete abuse-mailbox fields in all objects that do not define an IRT, and delete the trouble field everywhere until end of 2012. 5. Advantages and disadvantages of the proposal ------------------------------------------------ 5.1 Advantages - Networks will be able to supply their own, direct contact information for abuse departments. - Abuse complaints will not be sent to the "wrong" contact any more. - This permits greater administrative and operational flexibility, and faster abuse handling will be possible. - APNIC and RIPE have the same abuse contact policy in place. Keeps things easier. - Projects like RIPE Abuse Finder will be more easy to implement and could work more efficient. 5.2 Disadvantages - No disadvantages are foreseen. 6. Effect on RIPE members --------------------------- There will be no immediate affect for RIPE members with existing resource registrations already in the RIPE Whois Database. However, members will need to add a reference to the mandatory IRT object in the following situations: - The first time members attempt to update an existing inetnum, inet6num or aut-num object - When members add new inetnum, inet6num or aut-num objects 7. Effect on NIRs ------------------ It would be of benefit to the whole Internet community if NIRs were to implement a similar abuse contact scheme in their whois databases. But this would be another proposal. 8. References -------------- [1] Abuse Contact Information in the AfriNIC service region (Proposal- Draft) http://www.afrinic.net/docs/policies/AFPUB-2010-GEN-002.htm [2] prop-079: Abuse contact information http://www.apnic.net/policy/proposals/prop-079 [3] Introduction to ARIN's Database https://www.arin.net/knowledge/database.html#abusepoc [4] There is no formal documentation on abuse-c in inetnum and inet6num objects, but for documentation on the abuse-c in ASN records, see LACNIC Policy Manual (v1.3 - 07/11/2009) http://lacnic.net/en/politicas/manual4.html
On Thu, Sep 30, 2010 at 11:48:56AM +0200, Tobias Knecht wrote: Just few comments.
Currently within the RIPE region, the biggest problem for network operators is to know the best place to publish abuse contact information. (IRT, abuse-mailbox, remark-fields, and in addition to that, in which object they should publish them?) On the other hand abuse reporting parties having a huge problem by finding a correct abuse contact in the variety of possibilities.
Since there is a specialized object (IRT) for abuse contacts, this should be mandatory, to stop the uncontrolled growth.
Your arguments could be summarize like that: "there is a mess". Making irt object mandatory has nothing to do with cleaning it up. Yet, I do think that making it the only place of putting "abuse contact" is ok.
4.3 Delete abuse-mailbox fields in all objects that do not define an IRT, and delete the trouble field everywhere until end of 2012.
I don't agree to delete the trouble field everywhere since those are in remarks right now and remarks are just free text remarks. ;-)
- Networks will be able to supply their own, direct contact information for abuse departments.
They are able to do that right now. Nothing new.
- Abuse complaints will not be sent to the "wrong" contact any more.
Ekhm. Don't take me wrong. I know only one well known organization which sends me abuse complaints using wrong data. It is abusix.org. And I do have proper contact information put in person/role/inetnum/aut-num objects for all of my customers and I do a regular cleanup and updates.
5.2 Disadvantages
- No disadvantages are foreseen.
A lot of work for LIR staff.
7. Effect on NIRs ------------------
It would be of benefit to the whole Internet community if NIRs were to implement a similar abuse contact scheme in their whois databases. But this would be another proposal.
Do we have NIRs in RIPE region?? ;-) Best regards, Piotr Strzyżewski -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
participants (10)
-
Gert Doering -
Jørgen Hovland -
Karl-Josef Ziegler -
Leo Vegoda -
Peter Koch -
Piotr Strzyzewski -
Richard Cox -
Ronald F. Guilmette -
Tobias Knecht -
Tobias Knecht