Hi all,

At the start of the proposal it mentions "it is not clear in which of these role objects it should be preferred.", but it's not clear to me at by the end of the document why I should prefer an abuse-c attribute to an irt object.

The IRT Object was degraded in the last few years. For example the creation process was made pretty simple to allow more people to use it as a abuse-c. The idea would be to go back to the original intent of an IRT Object. So if you are running a cert I would suggest using the IRT, if you are running an abuse department I would suggest using the abuse-c and if you are running both, like many huge ISPs already do, I would suggest to use both.

Also: "there will be some automated clean up of users data to reorganize abuse contact references where possible." Is that expanded on anywhere?

The clean up will be pretty tricky. We can not clean up remark fields with abuse contact data. But we could for example ask members if the remark fields are still required, if the remark field contains something with "abuse" as soon as they make changes. We would like to clean up as much as possible in an automatic way, but if that is not possible it has to bee looked at in a specific way. Thanks, Tobias -- abusix

Hi again,

This approach would be quite contrary to goals of the proposal (such as: ".. it helps all kinds of institutions to find the correct abuse contact information more easily"). Most users cannot distinguish between a CERT or an abuse department.

Also, I cannot see why implementing another object holding the same data as an IRT would make things better.

You are quite right. At the moment, but few years ago, the IRT object was not intended for abuse departments handling outbound abuse. IRT was originally intended for certs exchange information about security issues. And that is exactly what the IRT should be again, with all the security measures, that were mandatory at the very beginning and got canceled over time. Thanks, Tobias -- abusix

Hi,

Yet, a _single_ point of contact (mail, fax, phone, you name it) should is provided. The way abuse-related information is processed internally (outbound abuse communication vs. information sharing between teams) in institutions cannot (and won't) be solved in whois.

We do not want to solve it within whois, but we want to give the different teams the opportunity to publish their information. Many huge ISPs have a cert and an abuse department, which are sometimes located in different cities and do completely different work. A cert does want to contact the other cert and not the abuse department. A spamrun should be reported to the abuse department. In my personal opinion every ISP should have an abuse department to solve outbound abuse issues. And that is the abuse-c part and that why this is mandatory. If an ISP can afford or need a cert, he can publish this in whois as well.

...

And that is exactly what the IRT should be again, with all the security measures, that were mandatory at the very beginning and got canceled over time.

I am surprised, you have any examples for IRT objects were these measures were dropped?

If you look at this really old document http://www.ripe.net/data-tools/db/irt/ripe-irt-object-technical-how-to/#113 you will find under point 1.1.4 that signature, encryption and auth are mandatory fields, which they are not any more today. At least one of them is not mandatory anymore today. Couldn't find documentation at the moment. Thanks, Tobias -- abusix

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24/11/2011 14:23, Adrian wrote:

TI is the the one and only body to maintain IRT-objects. And, all of the above contraints are still mandatory. (At least they were until 11/2010).

IIRC and if I'm reading the document correctly anyone can create an IRT object but I've rarely if at all seen one used outside of the TI community, and most TI members let TI create their IRT objects. I wasn't really active in the TI community at the time this started so I may be completely wrong :) James - -- James Davis 0300 999 2340 (+44 1235 822340) Senior CSIRT Member Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk7OVU8ACgkQjsS2Y6D6yLxusAD/YykWudbZCyqVPqzrntVn3V6H u0dVvHzXztFNIg4wnZoA/jh4ysXk2rrz8sIoGK61lgfcURu94BHvAlyq3y/0PgFl =GhoS -----END PGP SIGNATURE----- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

Hi,

...

Many huge ISPs have a cert and an abuse department, which are sometimes located in different cities and do completely different work. A cert does want to contact the other cert and not the abuse department. A spamrun should be reported to the abuse department.

You have an ideas about the difference in work that certs and abuse departments do, but I'm sure that we all have slightly different definitions. These differences are likely to be extremely subtle to someone outside of the CSIRT and abuse communities.

I'm not convinced that the differences in these roles are is in fact obvious, or that the choice between either or both of these roles is clear to a new member of the RIPE community or someone reporting a network event. I think I understand what you are trying to achieve by having these two options available, but we need to be sure that this choice makes it easier for people involved at all stages to do the right thing.

And that is exactly what we are trying to do. ;-) First of all the abuse-c (Abuse Contact) gives a better idea that it is a Contact about Abuse, than mnt-IRT will ever do. New members or people outside the abuse community should be able to understand it more easily. Creating an abuse-c is much more easy than creating an IRT object. Using the abuse-finder tool giving back the abuse-mailbox attribute of the abuse-c will help RIPE NCC to reduce Queries in the DB and makes things for people much more easy to query for. It makes the hole person, role, organization object mechanism much more easy, than it is at the moment. The whole cleanup will lead to easier understandable information and makes things easier. And at the end, if all the IRT Object holders show up and say we do not need the irt object anymore as soon as we have an abuse-c in place, there would not be a reason to keep the irt any longer. This is not part of this proposal, but the abuse-c will make things more understandable, than the IRT. Don't get me wrong, I do not want to get rid of the IRT, just mentioning the possibilities. Why we are not using the IRT and make it mandatory? There have been several reasons for this. We also discussed about this option for a while. Thanks, Tobias -- abusix

Hi,

...

And at the end, if all the IRT Object holders show up and say we do not need the irt object anymore as soon as we have an abuse-c in place, there would not be a reason to keep the irt any longer.

If this proposal was adopted then I can't see the IRT object being widely adopted outside of the TI community. I'm not saying that this is a good or a bad thing but readers of the proposal should be made aware of this. I think it needs to be mentioned in the proposal as an argument against it.

It was over all not widely adopted until now. I do not know how much IRT Objects we ave at the moment and how much percent of the IP space they cover. But you are right, I think this could be added as an argument against it. I have made a notice and I will add it with the next version. Thanks for mentioning it.

That would at least acknowledge how you think this proposal will lessen the confusion of how to publish contact information and not simply add another choice into the confusion.

True. Thanks, Tobias -- abusix

...

It was over all not widely adopted until now. I do not know how much IRT

In Germany, every institution being hooked up by DFN is provided an IRT-object. This may be applicable for other european NRENs as well.

Yes maybe, but how big is the piece of the whole RIPE IP Space? I have something in mind about 210 IRT objects overall. But can't find the stats on RIPE Labs at the moment. Thanks, Tobias -- abusix

Hi, Suresh Ramasubramanian wrote:

it is an interesting question, followed by the 'what is ripe to do in cases where is requirement isnt complied with, or where it is fraudulent' question

At least an abuse-c is much nicer to parse for the normal people than an IRT object, because it will appear in the normal whois output for any IP asked for. And its surely useable automatically. And a required abuse object is really needed anyway ... The proposal should also answer the following question: - are abuse remarks, the abuse-mailbox field or IRT-abuse field depricated or could they be used beside the non mandatory abuce-c - will there be any kind of automatic migration of existing abuse contact to the abuse-c ? - will it be possible for an LIR to select something like: (x) use the following default abuse-c for all inetnum objects: ______ if there is non explicitly specified ? - how or who will test, if an abuce-c is correct ? - will the whois state, who to contact (or wich URL to visit), if an abuse-c isnt reachable or correct ? - what is happening, if the abuce-c isnt correct ? This all leads to the old question if the RIPE NCC is willing to punish LIRs, that do not answer abuse reports. Kind regards, Frank

--srs (iPad)

On 23-Nov-2011, at 20:18, Leo Vegoda<leo.vegoda@icann.org> wrote:

...

Hi,

The proposed policy text includes:

"The role objects used for abuse contact information will be required to contain a single "abuse-mailbox:" attribute which is intended for receiving automatic and manual reports about abusive behavior originating the resource holders' networks."

Do the proposers intend the requirement for the "abuse-mailbox:" attribute to be enforced in any way and if so, how?

Thanks,

Leo

-- Mit freundlichen Gruessen, -- 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

Hi,

Can you please clarify if the only requirement is that an abuse-c be published? For instance, if an LIR published an abuse-c with 100% bogus contact data, would that meet the requirements and so avoid the address space being reclaimed?

The reqiurement that is defined in the proposal is that an abuse-c has to be published. The abuse-c will reference a person, role or organization object. The abuse-c is not an object itself. This means, the bogus data will be handled in the same way bogus data is handled by RIPE NCC. Hope this clarifies your question. Thanks, Tobias -- abusix

Hi,

No, it doesn't really answer my question. I am no longer familiar with the way the RIPE NCC handles bogus data published in the database but as you are proposing that failure to comply with the policy should lead to deregistration, it seems only reasonable that the proposers should explicitly state what they intend to happen in various circumstances.

I want to know whether this is proposal is going to result in large amounts of unmaintained data of questionable quality being registered, or whether some kind of maintenance process is envisaged and if so what that should be.

I'm and the Task Force are not proposing anything about bogus data. The proposal is proposing to introduce an abuse-c with some special features. What happens with bogus data is not and can not be part of this proposal. I fully understand that this is an issue that has to be covered, but not within this proposal. RIPE NCC has processes in place that cover these issues and as far as I know, is steadily working on improving these to increase data quality. If there is a need for changes in these processes, this should be covered by another proposal. In my personal opinion the proposal has a chance to increase data quality. Since there is not a new object and the existing objects can be used but have to be "upgraded" with the abuse-mailbox attribute. There is a need for maintainers to go over at least the objects they want to use for abuse-c and review the data given. But that is a personal opinion. Thanks, Tobias -- abusix

Leo,

You previously wrote, that "If there is no cooperation, this can go down until the deregistration." I don't see how a threat of deregistration fits alongside a statement that dealing with bogus data is outside the scope of your proposal.

Because you asked what will happen if there is no cooperation and I said that the new abuse-c will be handled in this case as every other object in the RIPE Database. The "what could happen" is described in this document (https://www.ripe.net/ripe/docs/ripe-517#b1). And this document is existing and already in use, so there is no need to describe the same things in our proposal again. And from that point of view dealing with bogus data is outside the scope of this proposal.

...

RIPE NCC has processes in place that cover these issues and as far as I know, is steadily working on improving these to increase data quality. If there is a need for changes in these processes, this should be covered by another proposal.

I searched the RIPE NCC's web site and could not find any description of systemic processes for evaluating and improving the quality of registration data. Right now, I don't know whether your threat of deregistration is credible. However, I would suggest that if you want a data maintenance process to apply to the abuse-c object, then you should describe it. As you seem to want the RIPE NCC to remove the registration of address space if abuse-c's are not maintained appropriately, the standards required should be explicit and either included in the policy text or referenced by it.

If RIPE NCC is getting notified about bogus data in any of the objects, they first of all contact the responsible member and try to solve the issue that way. If this is not working and the member is not cooperative RIPE NCC can deregistrate. Nobody wants that to happen, but at the end it is the decision of RIPE NCC and I'm absolutely sure, that they take these things very serious. I do not know why this process is not described somewhere on the website or why you haven't been able to find it, if it is there. But I guess it is quite clear that RIPE NCC does not deregistrate members immediately without trying to get in contact first. If you think there is a need to have this process described in a paper we should ask RIPE NCC if they would mind to do it. Maybe they are already working on something, since the data accuracy issue is a big one and needs attention. Tobias -- abusix

Leo Vegoda <leo.vegoda@icann.org> writes:

However, I would suggest that if you want a data maintenance process to apply to the abuse-c object, then you should describe it. As you seem to want the RIPE NCC to remove the registration of address space if abuse-c's are not maintained appropriately, the standards required should be explicit and either included in the policy text or referenced by it.

I think this is a valid argument. The proposal should contain the desired outcome as clear and explicitly as possible. And I don't think the desired outcome is to just have a role or person object referenced as the abuse contact, but to actually have abuse contacts. -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\

On Tue, Nov 29, 2011 at 08:58:36AM +0100, Tobias Knecht wrote: Hi,

The outcome is, to have an abuse-c in place. That is all.

In my opinion it would not make any sense to describe any measures for abuse-c. If we look at data accuracy we need to look at all the data in the database and not only at one small piece.

If I am correct, the proposal is on the improvement on finding the correct and valid contacts for abuse handling. Unfortunately, the proposal does only mention a possible techical solution on how this data can be stored. It leaves speculation on how the goal (such as valid contact data) can be achieved, which is (for my opinion) the most crucial part. (I am not talking about stuff that is beyond not cooperating members, etc.)

So please keep it simple and lets discuss about the introduction of an abuse-c and ask the Task Force to work on a common data accuracy part after this proposal.

If the above is not covered in this very same proposal, you should do so (maybe in a second proposal) before abuse-c is released. I am convinced that if you specify "just another object", the situation won't be improved (in terms of finding the right contact data). Cheers, Adrian

Hi,

If I am correct, the proposal is on the improvement on finding the correct and valid contacts for abuse handling. Unfortunately, the proposal does only mention a possible techical solution on how this data can be stored. It leaves speculation on how the goal (such as valid contact data) can be achieved, which is (for my opinion) the most crucial part. (I am not talking about stuff that is beyond not cooperating members, etc.)

Yes this proposal is only mentioning how the data should look like and how it is stored. Because the Task Force was not intended to do more so far. We all have talked about the problems and how we could solve them, but this was not the intention. Community wanted us to solve the problem on how abuse contact information will show up in the RIPE Database, because the first proposal was too technical and went into a wrong direction. If Community wants the Task Force to go on and take care of the data accuracy. That is fine and I know that the Task Force will be happy to do so. But this proposal is a first step into this direction. Maybe it will get clearer as soon as RIPE NCC has published their implementation thoughts. Since I can not talk for RIPE NCC in behalf of implementation and operational issues I have to stop this discussion here and take care that RIPE NCC is joining this discussion. Never the less thanks for your thoughts and thanks for the suggestions.

+1, why not review and add how to accomodate the accuracy of data.

Because we can not boil the ocean at once. ;-) The implementation of this proposal will take steps to make things easier while looking at data accuracy. We have an accuracy problem in the whole database and not only with the abuse-c. So let's differentiate and mix not up things. Thanks, Tobias -- abusix

Regards,

Aftab A. Siddiqui.

Dan Luedtke wrote, On 2012-01-18 08:39:

...

The abuse-c will reference a person, role or organization object. I followed the discussion and looked at some RIPE Database entries to get an idea what the problem was. With the reference to roles and/or organizations, for most space holders it will be easy to comply with

On Mon, Nov 28, 2011 at 10:08 PM, Tobias Knecht<tk@abusix.com> wrote: the proposed policy.

I support this proposal, even if the wording might not be the best at the moment (I guess it will change during the process, I saw that on other policies already).

I too support the proposal, but under these conditions: the new handle "abuse-c" and the abuse contact info under this handle must be _mandatory_, not optional, and it must be a functioning email address, not a web link etc. A non-functional abuse email contact shall mean an abuse itself. To automate the task of abuse reporting (and of abuse processing at the receiver side) I even would like to have several (2 or 3) abuse contact email addresses as there are several kinds of abuses (spam with ads, spam with criminal intent, hacking attempts, flood attacks/(D)DoS, portscans, service attacks, copyright infringement, impersonation, sockpuppetry, insult/discrimination, ...), but I think this should be made some time later in a new proposal when enough experience has been collected with "abuse-c". Another method would be to use just one abuse address but use a specific keyword in the subject line for automatic filtering/routing the report to the right department at the receiver side. These keywords (key) should be the same for all organizations, ie. it shall be standardized and published by the RIR. But as said, these extended methods can be done some time later in a new proposal. For newcomers: here's the ongoing proposal and some related pages: http://www.ripe.net/ripe/policies/proposals/2011-06 https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database http://www.ripe.net/ripe/groups/tf/abuse-contact Minutes and archives: http://www.ripe.net/ripe/groups/wg/anti-abuse Rgds, U.Mutlu www.mutluit.com

Dan Luedtke wrote, On 2012-01-18 17:19:

On Wed, Jan 18, 2012 at 12:27 PM, U.Mutlu<security@mutluit.com> wrote:

...

I even would like to have several (2 or 3) abuse contact email addresses as there are several kinds of abuses (spam with ads, spam with criminal intent, hacking attempts, flood attacks/(D)DoS, portscans, service attacks, copyright infringement, impersonation, sockpuppetry, insult/discrimination, ...),

I like this kind of information to be embedded in the protocol/format used for reporting. There are already standards being worked on, or even used. This should not be part of the RIPE database itself.

I guess you mean ARF/MARF (RFC 5965; http://www.ietf.org/dyn/wg/charter/marf-charter); yes, makes sense to handle the details therein. Of course ARF/MARF as well depends on a abuse contact, so we need a mandatory standard to follow, and therefore the current proposal of the wg should be ratified as soon as possible.