- anti-abuse-wg - mailman.ripe.net

[Moderated]
by Moderated 12 Dec '11

12 Dec '11

This message has been removed from the archive.

1 0

Re: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database)
by chrish＠consol.net 08 Dec '11

08 Dec '11

Hi! [...] > but business rules will require it to be [...] I didn't find any "business rules" document at RIPE. >From the thread I understand that the intention is to make the abuse-c an actually mandatory attribute, at the same time kind of removing the e-mail attribute and making the abuse-mailbox by definition a bulk target. Now I have to think about a crowd of real persons with a ripe handle, referenced as admin-c for their objects. They would have to add an abuse-c (or otherwise somebody will try to take their resources away from them!?), i.e. they will usually just add their e-mail there once more (if they don't have an abuse-mailbox attribute yet - probably because they don't need it because the value in the e-mail is perfectly what they want to communicate for this purpose as well) - while this email was made a bulk target by definition (in which case they probably even preferred to remove the abuse-mailbox if they had one in favour of their e-mail attribute - which would just be made impossible by the proposal), and at the same time their e-mail would be made unusable. One hell of a vision you got there, I'd say... ;) [though not explicitly stated, the following seems to be meant as justification of the proposal] > Currently within the RIPE NCC service region, it is not clear whether to use the "abuse-mailbox:" attribute, the "remark:" attribute or an irt object. And since the "abuse-mailbox:" attribute can be added to various role objects, it is not clear in which of these role objects it should be preferred. When I read that I assumed it had to mean that it is proposed to drop "abuse-mailbox", "remark" and the irt object. Later in the thread I had to find out that it isn't. In case the mentioned attributes/objects are really to be dropped in favour of the single new attribute, I might see a benefit in simplifying things. I don't say yet that this justifies a policy change, but at least there would be some sort of point in it... The implementation document kind of summarizes this aspect quite drastically, too. It describes the goal of 'going back to basics', 'avoiding complexity' in quite some length, and concludes in adding several attributes, objects, and quite some mainly undefined policy stuff while removing nothing at all. In short I can't see any benefit from this proposal. It doesn't simplify things, it makes things (including finding abuse contact information) more complicated and for a huge part of the community it introduces severe problems. We're better off as it is now. The "Arguments supporting the proposal" are in my eyes simply unsustainable. Another cue regarding the possible aim I found was: "The outcome is, to have an abuse-c in place. That is all." Well, that's not true as discussed above, there are major problematic implications, and on the other side, simply to have another attribute doesn't seem like a valid justification to me. I mean, it's not "to have an abuse-mailbox", which would bear some sort of sense in itself in my eyes - while of course this has been done already. Actually I do not even see the motivation for an 'abuse industry' to lobby this at all!? But I don't think that this kind of policy should be following particulate interest but should be universal anyway. Like this: - a resource has an administrative contact (complaints - whether abuse or not - are administrative issues) - a contact can have an explicit address for abuse reports. In case the contact chose to not have/want/need a special abuse address, there are still the canonical addresses for this contact. This is what we have, and while there might be problems somewhere that should or could be addressed, I don't see the problem the 2011-6 proposal fixes (or actually even formally addresses)!? If you want to force every resource holder to have and publish an email that is explicitly meant to be bulk-spammed, you should propose exactly this (i.e. making an abuse-mailbox mandatory for the admin-c and announcing it as proper use to bulk spam these addresses). As a victim of this I'd ofc still be very much against this. And once again, I'm really wondering what the businesscase might be to motivate such a situation... Making the abuse-c attribute actually mandatory as described, imho is a very very bad idea for the reason given above. Effectively removing the e-mail attribute imho is too, though probably sligthly less important than the previous issue. Well, at least time to update the "Arguments opposing" paragraph, I'd say... (dropping the proposal wouldn't be wrong either, I'd say) Regards, Chris

4 6

Call for participation in IETF WG on abuse reporting
by Alessandro Vesely 08 Dec '11

08 Dec '11

The MARF WG http://datatracker.ietf.org/wg/marf/ issued RFC 5965 for the abuse reporting format (ARF). RFC 6449, Complaint Feedback Loop Operational Recommendations, is an informational document that originated in MAAWG. The activity of MARF WG recently decreased and it apparently needs to get invigorated with the participation of newcomers who are willing to devolve their interest and experience in abuse reporting to the community. If that's your case, please review one or more drafts in that page and post comments on the MARF mailing list. In particular, draft-ietf-marf-reporting-discovery is an alternative to whois lookups, while draft-ietf-marf-as is an application statement for RFC 6449, which may modify or complement any operational recommendation contained therein, e.g. by merging in draft-vesely-marf-abuse-reporting. The participation called for here is an occasion to standardize how abuse reporting is to be done, thereby complementing the work carried out by this WG and ACM-TF. TIA

1 0

ripe whois - regexp search / full text search on the command line
by Suresh Ramasubramanian 07 Dec '11

07 Dec '11

I can't do this through the command line though I can do it in arin, say - use a regexp and find a full list of netblocks allocated to a spammer For example there's a brazilian spammer with multiple sbl listings, who has lots of /27s and /28s swipped to him all over multiple /16s on an European ISP Finding him by command line whois doesn't work at all, but I can get all his netblocks by searching in https://apps.db.ripe.net/search/full-text.html -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

1 0

Re: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database)
by Shane Kerr 05 Dec '11

05 Dec '11

All, On Wed, 2011-11-23 at 14:46 +0100, Emilio Madaio wrote: > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-06 As it is written I support this proposal. I am worried about the implication that an "abuse-c:" will be forced on all allocations. Without clear policies about what is required of such an abuse handling role, then organisations can simply set this to an unanswered mailbox, which doesn't actually improve the situation. But since that is not explicitly written in the proposal, I support the proposal. :) -- Shane

3 2

Re: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse ContactManagement in the RIPE NCC Database)
by Briaut perso 04 Dec '11

04 Dec '11

Hello ! I speak french only René BRIAUT 115 Cours Fauriel 42100 SAINT ETIENNE ( 04.77.46.96.07 et 06.07.61.29.49 rbriaut(a)wanadoo.fr -----Message d'origine----- De : anti-abuse-wg-bounces(a)ripe.net [mailto:anti-abuse-wg-bounces@ripe.net] De la part de Emilio Madaio Envoyé : mercredi 23 novembre 2011 14:47 À : policy-announce(a)ripe.net Cc : anti-abuse-wg(a)ripe.net Objet : [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse ContactManagement in the RIPE NCC Database) Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-06 We encourage you to review this proposal and send your comments to <anti-abuse-wg(a)ripe.net> before 21 December 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

3 2

Re: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database)
by Aftab Siddiqui 01 Dec '11

01 Dec '11

Hi Tobias, So the RIPE NCC explanation and proposal states that the intention is to add abuse-c object (thats it). In this form do you think it will going to add any value to over all abuse reporting, IMHO the accuracy of data will always remain the biggest issue no matter how many objects you add, same is the case with IRT. But as a first step, I support it. Regards, Aftab A. Siddiqui > > On Wed, Nov 30, 2011 at 10:39 PM, Tobias Knecht <tk(a)abusix.com> wrote: >> >> Thanks to Denis and RIPE NCC to come up with this view of the planned >> implementation. >> >> Thanks, >> >> Tobias >> >> -- >> abusix >> >> >> Am 30.11.11 16:25, schrieb Denis Walker: >> > Dear Tobias and others >> > >> > The RIPE NCC Database Group has now published an article on RIPE Labs >> > with a detailed explanation of how we propose to implement abuse >> > handling with an "abuse-c:" attribute referencing a ROLE object. >> > >> > https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database >> > >> > Regards >> > Denis Walker >> > Business Analyst >> > RIPE NCC Database Group >> > >> > >> > On 29/11/11:49 4:49 PM, Tobias Knecht wrote: >> >> Hi Denis, >> >> >> >> thank you very much! Looking forward the document. >> >> >> >> Thanks, >> >> >> >> Tobias >> >> >> >> >

2 1

Spesific area of concern on WHOIS data.. "PE "
by Huopio Kauto 29 Nov '11

29 Nov '11

I have seen a lot of malicious activity concentrated on IP resources allocated to parties identifying as "PE Nnnnnn Nnnnnnnn", something like a private enterprise. I would like to recommend a spesific constintency check on all resources allocated to parties identifying themselves with a name starting with "PE ".. --Kauto

2 1

Re: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database)
by Tobias Knecht 29 Nov '11

29 Nov '11

Hello all, thanks for the already ongoing discussion about the new abuse contact policy proposal. I will try to clarify some things. We had some really technical discussions about this with database people from RIPE NCC and came up with this idea. So let's have a look at it. If we use a person object as an example, this person object can be referenced for example by an admin-c or tech-c attribute at the moment. In future it can be referenced by the abuse-c as well, BUT to create this reference the person objects needs to have an abuse-mailbox attribute. If there is no abuse-mailbox attribute it can not be referenced by the abuse-c. This will be done by the business logic. Same when you query for an ip range - admin-c, tech-c and abuse-c can be the same person, but output will show an abuse-mailbox attribute in the abuse-c part. So at the end it is only a matter, if the attributes requested by the business rules are existing for the intended use of the object. I will answer the other questions on the mailing list directly. Just wanted to give a real quick overview about the technical idea of the Task Force and RIPE NCC. Thanks, Tobias -- abusix

6 7

Re: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database)
by Aftab Siddiqui 24 Nov '11

24 Nov '11

It states "The syntax will make this an optional attribute". We are dealing with inconsistent records even making it mandatory in the APNIC region. How would it help? or I didn't understand properly, can anyone elaborate? Regards, Aftab A. Siddiqui On Wed, Nov 23, 2011 at 6:46 PM, Emilio Madaio <emadaio(a)ripe.net> wrote: > > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-06 > > We encourage you to review this proposal and send your comments to > <anti-abuse-wg(a)ripe.net> before 21 December 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > >

3 3