RE: [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an abuse monitor system
-----Original Message----- From: Frank Gadegast [mailto:phade@www.powerweb.de] Sent: Thursday, April 08, 2010 6:42 PM To: Thor Kottelin Cc: anti-abuse-wg@postboy.ripe.net
-----Original Message----- From: anti-abuse-wg-admin@ripe.net [mailto:anti-abuse-wg- admin@ripe.net] On Behalf Of Bradley Freeman Sent: Thursday, April 08, 2010 4:45 PM To: 'Frank Gadegast'; anti-abuse-wg@ripe.net
And if the only benefit is a common abuse alias, hasn't this has already been suggested with an abuse@ address in RFC2142 - Mailbox Names for Common Services, Roles and Functions which is not RIPE region specific?
It is not always obvious which abuse@ domain should be selected for a particular IP address. I like the suggestion of routing reports according to the IP address of the abuse source.
Not getting it.
I apologise. Allow me to rephrase: Any organisation to which net space is allocated or assigned may own zero, one or several Internet domains. It may be difficult to know exactly what to type on the domain side of an abuse@ address. Your proposal avoids this issue. This is an advantage of your proposal as compared with RFC 2142. -- Thor Kottelin http://www.anta.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Any organisation to which net space is allocated or assigned may own zero, one or several Internet domains. It may be difficult to know exactly what to type on the domain side of an abuse@ address. Your proposal avoids this issue. This is an advantage of your proposal as compared with RFC 2142.
This functionality is already provided by the irt object, maybe it would be more beneficial to change the policy to require that the irt-object contains valid information. Bradley -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.0.0 Charset: UTF-8 wsBVAwUBS74KGjR8IIjdC+5SAQIMMQgAhc/hROUOANw1hjo9Cku/FL3kXE73XuSe z5fmRnopHbxOft1pEgBfdbBrMePZIjmJbASKyeQYNVBuA8mOESrVLMqsujBmxz2v ovErYMNsch58OJsb9Ob2wbMbkeKsGLvOMAMxoy+Dln9wo8c0wEzt7LM4puYogLrd HQ8Dlq0iofiGX6p9PK2r8Ja3WuGh6C9jmo7GLIRIa3O5u+iyo5zjMDJcrhs6brzs YeinCDqXbOD2e9q/Y6RNz633Jb8V2WndWSb9Iz9S7cqpgqAzfgutWFAPMtKj9HEV kc7LZ4h7mmMDw0cAdUkFVvpYbfHqMt/u2pjdIEXaQc+Cg8kl0eX3LQ== =8W67 -----END PGP SIGNATURE-----
Not getting it.
I apologise. Allow me to rephrase:
Any organisation to which net space is allocated or assigned may own zero, one or several Internet domains. It may be difficult to know exactly what to type on the domain side of an abuse@ address. Your proposal avoids this issue. This is an advantage of your proposal as compared with RFC 2142.
No, because the system generates email addresses only related to the IP address that causes the abuse. The monitoring system at RIPE NCC than "translates" this IP like email addresses to either the abuse address, that the member was putting into RIPEs system or the main member address, the member has to setup, when becoming a member. RIPE NCC knows best how to "translate" the IP like abuse email address to the members address, because RIPE NCC has best knowlegde about the allocation all member ownes. BTW: thats the main advantage of my draft ... nobody has to know the actual abuse address for a IP range or has to look it up via whois. Anybody that gets attacked knows the right address just by sending his report to 1.2.3.4@abuse.ripe.net when the IP 1.2.3.4 caused the abuse. Kind regards, Frank
-- Thor Kottelin http://www.anta.net/
Frank , How do you propose to do this Ip to mail Address translation ? BR Balaji On Thu, Apr 8, 2010 at 11:27 PM, Frank Gadegast <phade@www.powerweb.de>wrote:
Not getting it.
I apologise. Allow me to rephrase:
Any organisation to which net space is allocated or assigned may own
zero, one or several Internet domains. It may be difficult to know exactly what to type on the domain side of an abuse@ address. Your proposal avoids this issue. This is an advantage of your proposal as compared with RFC 2142.
No, because the system generates email addresses only related to the IP address that causes the abuse.
The monitoring system at RIPE NCC than "translates" this IP like email addresses to either the abuse address, that the member was putting into RIPEs system or the main member address, the member has to setup, when becoming a member.
RIPE NCC knows best how to "translate" the IP like abuse email address to the members address, because RIPE NCC has best knowlegde about the allocation all member ownes.
BTW: thats the main advantage of my draft ... nobody has to know the actual abuse address for a IP range or has to look it up via whois. Anybody that gets attacked knows the right address just by sending his report to
1.2.3.4@abuse.ripe.net
when the IP 1.2.3.4 caused the abuse.
Kind regards, Frank
-- Thor Kottelin http://www.anta.net/
Frank ,
Hi,
How do you propose to do this Ip to mail Address translation ?
Im sure, that RIPE NCC knows what IP address belongs to wich allocation (like they know when answering whois queries) and that they then know wich member owns this allocation. That should be not more than two database lookups for RIPE NCC. And a third one to find his abuse address the LIR entered into the system ... 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
BR Balaji
On Thu, Apr 8, 2010 at 11:27 PM, Frank Gadegast <phade@www.powerweb.de>wrote:
Not getting it.
I apologise. Allow me to rephrase:
Any organisation to which net space is allocated or assigned may own
zero, one or several Internet domains. It may be difficult to know exactly what to type on the domain side of an abuse@ address. Your proposal avoids this issue. This is an advantage of your proposal as compared with RFC 2142.
No, because the system generates email addresses only related to the IP address that causes the abuse.
The monitoring system at RIPE NCC than "translates" this IP like email addresses to either the abuse address, that the member was putting into RIPEs system or the main member address, the member has to setup, when becoming a member.
RIPE NCC knows best how to "translate" the IP like abuse email address to the members address, because RIPE NCC has best knowlegde about the allocation all member ownes.
BTW: thats the main advantage of my draft ... nobody has to know the actual abuse address for a IP range or has to look it up via whois. Anybody that gets attacked knows the right address just by sending his report to
1.2.3.4@abuse.ripe.net
when the IP 1.2.3.4 caused the abuse.
Kind regards, Frank
-- Thor Kottelin http://www.anta.net/
--0016e648cf9ac832e20483be8f1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Frank , <br><br>How do you propose to do this Ip to mail Address translatio= n ? <br><br>BR <br>Balaji <br><br><div class=3D"gmail_quote">On Thu, Apr 8,= 2010 at 11:27 PM, Frank Gadegast <span dir=3D"ltr"><<a href=3D"mailto:p= hade@www.powerweb.de">phade@www.powerweb.de</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">><br> > ><br> > > Not getting it.<br> ><br> > I apologise. Allow me to rephrase:<br> ><br> > Any organisation to which net space is allocated or assigned may own z= ero, one or several Internet domains. It may be difficult to know exactly w= hat to type on the domain side of an abuse@ address. Your proposal avoids t= his issue. This is an advantage of your proposal as compared with RFC 2142.= <br>
<br> No, because the system generates email addresses only related to the IP add= ress<br> that causes the abuse.<br> <br> The monitoring system at RIPE NCC than "translates" this IP like = email addresses<br> to either the abuse address, that the member was putting into RIPEs system<= br> or the main member address, the member has to setup, when becoming a<br> member.<br> <br> RIPE NCC knows best how to "translate" the IP like abuse email ad= dress<br> to the members address, because RIPE NCC has best knowlegde about<br> the allocation all member ownes.<br> <br> BTW: thats the main advantage of my draft ... nobody has to know<br> the actual abuse address for a IP range or has to look it up<br> via whois. Anybody that gets attacked knows the right address<br> just by sending his report to<br> <br> <a href=3D"mailto:1.2.3.4@abuse.ripe.net">1.2.3.4@abuse.ripe.net</a><br> <br> when the IP 1.2.3.4 caused the abuse.<br> <br> <br> Kind regards, Frank<br> <br> ><br> > --<br> > Thor Kottelin<br> > <a href=3D"http://www.anta.net/" target=3D"_blank">http://www.anta.net= /</a><br> ><br> ><br> ><br> <br> </blockquote></div><br>
--0016e648cf9ac832e20483be8f1c--
frank@powerweb.de wrote:
No, because the system generates email addresses [1.2.3.4@abuse.ripe.net] only related to the IP address that causes the abuse.
No, it doesn't. The mail will go to wherever some human or robot *assumes* the spam cause to be. Never seen a complaint which was mis-directed to because some bozo fell prey to faked headers? If I understood your draft section 5 correctly, you think that there are actually people who consider researching "whois" records too complicated but, at the same time, are able to do a decent analysis of email headers? I've never met members of this species. And I'd be afraid if I were *forced* (by RIPE) to read and repsond to their spam reports. Your policy draft is extremely week on th only policy point it contains: Section 5 "Advantages": [...] RIPE NCC can ensure that all allocations have a working abuse address. [...] Like, how? As someone else has already pointed out: redirecting all reports to /dev/null would make your control system happy -- no bounces. It all gets back to human checks: Internet user U complaints (at the RIPE) about LIR L, saying something like "unrepsonsive LIR, restract its allocation containing 62.67.229.200". Your proposal would have to state the further course of action (i.e., "the policy"). In particular, please be clear on legal issues. When U complains about "the contact for 62.67.229.200", the RIPE NCC should do what? Snail-mail two warnings, then "pull the plug" for 62.67.228.0/20 (or would it be the 62.67.0.0/16, because of "remarks: all abuse reports to abuse@level3.com")? The very next day, the three distinct end users of, say, 62.67.1.1, 62.67.231.254, and 62.67.255.254, respectively, get a bit upset that their businesses have RPSLy fallen off the Internet. Ooops. A merry round of "A sues B" follows. Anybody in this game who you think should be idemnified at this point? The RIPE NCC for example? How? Shifting the focus away from "forced policies" towards "useful tools": Any well-intentioned LIR/ISP will happily use whatever tools it can get its hands to be aware of any abuse of its network. It appears to me that simply monitoring your network ranges on various DNSBLs is achieving pretty much the same benefits (for the ISP/LIR) as your proposol does, without inflicting any work on the RIPE NCC to forward spam complaints and to collect statistics. You're kinda reinventing wheels many folks already use. You do seem to have a valid point about educating new LIRs/ISPs. Martin
Hello,
frank@powerweb.de wrote:
No, because the system generates email addresses [1.2.3.4@abuse.ripe.net] only related to the IP address that causes the abuse.
No, it doesn't. The mail will go to wherever some human or robot *assumes* the spam cause to be. Never seen a complaint which was mis-directed to because some bozo fell prey to faked headers?
Sure, thats what the backlink idea is for. So the member is free to categorize the report himself (where it would be detectable, if one member simply sets all his reports always to "false report, started not from our network" without any more details".
If I understood your draft section 5 correctly, you think that there are actually people who consider researching "whois" records too complicated
Sure, no normal mail user in Germany I know about knows what RIPE is or whois, they even do not know what a domain whois and e.g. the DENIC is, even if they have a own domainname. And that normal end user is not different in other coutries ...
but, at the same time, are able to do a decent analysis of email headers?
Point for you.
I've never met members of this species. And I'd be afraid if I were
Hm, maybe the system should be enhanced to that the system tracks the source doing it self, complicated but possible, like spamhaus or spamcop are doing it ... But then we have a real clearing system that has to be reliable (instead of just forwarding spam). In the end, this is the really first point against a system I described. Anybody ideas to solve that ? Otherwise the system will only good for professional and they know what whois is (even its still more complicated and non-mandatory information is still missing).
*forced* (by RIPE) to read and repsond to their spam reports.
Your policy draft is extremely week on th only policy point it contains:
Section 5 "Advantages": [...] RIPE NCC can ensure that all allocations have a working abuse address. [...]
Like, how? As someone else has already pointed out: redirecting all reports to /dev/null would make your control system happy -- no bounces.
Well, not that bad in the first step. They work, ok, there are not read, but the exist and work. These days we have thousand of abuse addresses that do not work, intentionally or not. It would be helpful to find those, that should work, but dont and warn the ISP about it on time ...
It all gets back to human checks: Internet user U complaints (at the RIPE) about LIR L, saying something like "unrepsonsive LIR, restract its allocation containing 62.67.229.200". Your proposal would have to
Funny IP :o)
state the further course of action (i.e., "the policy"). In particular, please be clear on legal issues. When U complains about "the contact for 62.67.229.200", the RIPE NCC should do what? Snail-mail two warnings, then "pull the plug" for 62.67.228.0/20 (or would it be the 62.67.0.0/16, because of "remarks: all abuse reports to abuse@level3.com")? The very next day, the three distinct end users of, say, 62.67.1.1, 62.67.231.254, and 62.67.255.254, respectively, get a bit upset that their businesses have RPSLy fallen off the Internet. Ooops. A merry round of "A sues B" follows. Anybody in this game who you think should be idemnified at this point? The RIPE NCC for example? How?
Hm, your a bit too quick here ... but I get the point.
Shifting the focus away from "forced policies" towards "useful tools":
Any well-intentioned LIR/ISP will happily use whatever tools it can get its hands to be aware of any abuse of its network. It appears to me that simply monitoring your network ranges on various DNSBLs is achieving pretty much the same benefits (for the ISP/LIR) as your
But there are that many ...
proposol does, without inflicting any work on the RIPE NCC to forward spam complaints and to collect statistics. You're kinda reinventing wheels many folks already use.
Yes, but I started a discussion of really important points I think (where this list was kind of sleeping for a while). My main question from today is still not answered (by nobody so far): If the community willing to accept, that RIPE members cause harm to other members without any consequences simply because they are lazy, uneducated, ignorant or without resources to prevent problem or maybe even because they provit or intended the problem ? Does "free internet" means that we have to live with that ?
You do seem to have a valid point about educating new LIRs/ISPs.
Well then ... 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
Martin
On 9 Apr 2010, at 15:38, Frank Gadegast , Dipl-Inform. Frank Gadegast wrote:
But there are that many ...
There are only a handful that really matter and anyone who actually cares is probably monitoring them Combine that with the "feedback" loops from AOL / MSN etc., and you've covered pretty much anything of any real importance
If the community willing to accept, that RIPE members cause harm to other members without any consequences simply because they are lazy, uneducated, ignorant or without resources to prevent problem or maybe even because they provit or intended the problem ?
That isn't a question that can be answered with a simple yes / no It's a grey area For example, if you were to report an issue to us which involved our main mail cluster it would probably be dealt with within a few minutes to a couple of hours (depending on what it was) However, if you were reporting an issue involving an IP or range of IPs that are used by a client of ours with dedicated / colo or even IP transit then it may take a lot longer for the issue to be fully resolved. Does that mean that we are not acting responsibly in your view? Or do you understand that we cannot simply unplug a chunk of our network that quickly? Is the delay causing "harm" ? Probably. Is that "harm" a huge problem? That depends on what the "harm" is. Network abuse comes in many shapes and forms. Email abuse could be a simple commercial email that you did not want to get OR it could be a much more serious problem such as a phishing email
Does "free internet" means that we have to live with that ?
What do you mean by "free"? free as in freedom? or Free as in cost? Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ 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 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
participants (6)
-
Balaji Naglagave -
Bradley Freeman -
Frank Gadegast -
Martin Neitzel -
Michele Neylon :: Blacknight -
Thor Kottelin