From furio+as at spin.it Mon Jul 1 09:28:38 2013 From: furio+as at spin.it (furio ercolessi) Date: Mon, 1 Jul 2013 09:28:38 +0200 Subject: [anti-abuse-wg] New Abuse Information on RIPE NCC Website In-Reply-To: <20130629201456.GG2706@Space.Net> References: <39804.1371411773@server1.tristatelogic.com> <51BFEBAB.4010708@CC.UniVie.ac.at> <20130618132923.GA4854@spin.it> <20130629134323.GA27051@spin.it> <20130629201456.GG2706@Space.Net> Message-ID: <20130701072838.GA30467@spin.it> On Sat, Jun 29, 2013 at 10:14:57PM +0200, Gert Doering wrote: > HI, > > On Sat, Jun 29, 2013 at 03:43:23PM +0200, furio ercolessi wrote: > > On Tue, Jun 18, 2013 at 03:29:23PM +0200, furio ercolessi wrote: > > > [...] > > > Now, RIPE-582 (February 2013) contains the following text: > > > > > > "6.6 Validity of an Assignment > > > All assignments are valid as long as the original criteria on which the > > > assignment was based are still valid and the assignment is properly > > > registered in the RIPE Database. If an assignment is made for a specific > > > purpose and that purpose no longer exists, the assignment is no longer > > > valid." > > > > > > Therefore, if the above premises are correct, spamming ranges are > > > classified "not valid" - simply because snowshoe spam was not the > > > motivation given to get the assignment. > > This paragraph mentions *assignments*, which is (in the context of LIRs) > what a LIR gives to it's customers. > > So indeed, if a customer is lying to the LIR, the assignment falls back > to the LIR (which makes a difference when the LIR's allocation is full > and they can't get more space because their assignments are not valid). > > This paragraph does not apply to the *allocation* give to the LIR from > the RIPE NCC. Sure, I fully understand that. The question remains. Who is supposed to classify the range as invalid ? Are invalid assignments revoked by RIPE NCC ? If not, what the 6.6 wording is there for ? What happens if an assignment is revoked and the customer continues to use the same allocated and now unassigned space as if nothing happened ? furio ercolessi From brian.nisbet at heanet.ie Mon Jul 1 10:29:43 2013 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Mon, 01 Jul 2013 09:29:43 +0100 Subject: [anti-abuse-wg] central whois In-Reply-To: <51CED23C.9030700@powerweb.de> References: <51C2C88D.9090704@powerweb.de> <51C2E7E8.9080304@ripe.net> <51C2EEE0.4040604@powerweb.de> <87bo70c25i.fsf@stepladder-it.com> <87zjuflqid.fsf@stepladder-it.com> <51C8312D.6070208@powerweb.de> <871u7mpm6y.fsf@stepladder-it.com> <51CD700A.9060206@powerweb.de> <87a9m99my9.fsf@stepladder-it.com> <51CED23C.9030700@powerweb.de> Message-ID: <51D13DF7.1080405@heanet.ie> Frank Gadegast wrote the following on 29/06/2013 13:25: > Benedikt Stockebrand wrote: >> Frank Gadegast writes: >> > Not at all. > Your getting personal here, so a personal answer. Let's all take this opportunity to stop getting personal. This is a general note, but sparked by this exchange. We're all professionals. Brian Co-Chair, RIPE AA-WG From ops.lists at gmail.com Mon Jul 1 11:08:40 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 1 Jul 2013 14:38:40 +0530 Subject: [anti-abuse-wg] New Abuse Information on RIPE NCC Website In-Reply-To: <20130701072838.GA30467@spin.it> References: <39804.1371411773@server1.tristatelogic.com> <51BFEBAB.4010708@CC.UniVie.ac.at> <20130618132923.GA4854@spin.it> <20130629134323.GA27051@spin.it> <20130629201456.GG2706@Space.Net> <20130701072838.GA30467@spin.it> Message-ID: And what if the LIR is complicit in this activity, to the extent of providing IP space no questions asked? On Jul 1, 2013 12:58 PM, "furio ercolessi" wrote: > On Sat, Jun 29, 2013 at 10:14:57PM +0200, Gert Doering wrote: > > HI, > > > > On Sat, Jun 29, 2013 at 03:43:23PM +0200, furio ercolessi wrote: > > > On Tue, Jun 18, 2013 at 03:29:23PM +0200, furio ercolessi wrote: > > > > [...] > > > > Now, RIPE-582 (February 2013) contains the following text: > > > > > > > > "6.6 Validity of an Assignment > > > > All assignments are valid as long as the original criteria on which > the > > > > assignment was based are still valid and the assignment is properly > > > > registered in the RIPE Database. If an assignment is made for a > specific > > > > purpose and that purpose no longer exists, the assignment is no > longer > > > > valid." > > > > > > > > Therefore, if the above premises are correct, spamming ranges are > > > > classified "not valid" - simply because snowshoe spam was not the > > > > motivation given to get the assignment. > > > > This paragraph mentions *assignments*, which is (in the context of LIRs) > > what a LIR gives to it's customers. > > > > So indeed, if a customer is lying to the LIR, the assignment falls back > > to the LIR (which makes a difference when the LIR's allocation is full > > and they can't get more space because their assignments are not valid). > > > > This paragraph does not apply to the *allocation* give to the LIR from > > the RIPE NCC. > > Sure, I fully understand that. > > The question remains. Who is supposed to classify the range as > invalid ? Are invalid assignments revoked by RIPE NCC ? If not, what > the 6.6 wording is there for ? What happens if an assignment is revoked > and the customer continues to use the same allocated and now unassigned > space as if nothing happened ? > > furio ercolessi > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Jul 1 11:58:41 2013 From: gert at space.net (Gert Doering) Date: Mon, 1 Jul 2013 11:58:41 +0200 Subject: [anti-abuse-wg] New Abuse Information on RIPE NCC Website In-Reply-To: References: <39804.1371411773@server1.tristatelogic.com> <51BFEBAB.4010708@CC.UniVie.ac.at> <20130618132923.GA4854@spin.it> <20130629134323.GA27051@spin.it> <20130629201456.GG2706@Space.Net> <20130701072838.GA30467@spin.it> Message-ID: <20130701095841.GB2706@Space.Net> Hi, On Mon, Jul 01, 2013 at 02:38:40PM +0530, Suresh Ramasubramanian wrote: > And what if the LIR is complicit in this activity, to the extent of > providing IP space no questions asked? In that case, the address space can be revoked. This is all covered in the Closures document that Brian already referenced to: http://www.ripe.net/ripe/docs/ripe-578 Gert Doering -- NetMaster -- have you enabled 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From ripe-anti-spam-wg at powerweb.de Mon Jul 1 12:35:48 2013 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Mon, 01 Jul 2013 12:35:48 +0200 Subject: [anti-abuse-wg] New Abuse Regulations In-Reply-To: <51CD487D.9070904@heanet.ie> References: <4803.1372366044@server1.tristatelogic.com> <51CD3F97.2000400@powerweb.de> <51CD487D.9070904@heanet.ie> Message-ID: <51D15B84.4080709@powerweb.de> Brian Nisbet wrote: > Frank Gadegast wrote the following on 28/06/2013 08:47: >> >> For a start Im really interested how the current revoking >> process at RIPE NCC actually looks like and examples >> how this process was actually used in the past ... >> I might have missed that, but maybe that was never >> comunicated to the list in detail. > > I don't have direct references for past use, but the Closure & > Deregistration document has been repeatedly communicated to this list. > > It is here in all its glory: > > http://www.ripe.net/ripe/docs/ripe-578 Looks like to me, that the NCC can only revoke resources or terminate contracts, because the member does not follow regulations like allocation size, db entries or is insolvent or similar, rather formal reasons. Any LIR or customer or a LIR can probably setup the contract and DB data in a way it fits those needs, but still use the resources for massive abuse. These seems to be also true for the audit process. The LIR can withdraw a customers resource, if the current usage does not comply to its initial order purpose, but the NCC cant do the same. Should it be not part of the audit process to check the current usage of sponsored resources against their initial purpose ? Then the following could happen: - the community askes the NCC to start an audit for a special resource/LIR because of constant abuse coming from that network - the NCC askes the LIR for the initial purpose of the sponsored resources - and ask him to check the current usage, because of massive abuse complaints Now the LIR (lets trust him in the first stage), can check and maybe revoke the resources. If the problems continue, NCC could start to audit the LIR itself ... At that stage, the NCC would need trustful data to proove, that the resources are massivly used for abuse and the big question is, how to either collect them at the NCC or how to get them from trusted third parties. Kind regards, Frank > > Brian > > From denis at ripe.net Mon Jul 1 18:10:34 2013 From: denis at ripe.net (Denis Walker) Date: Mon, 01 Jul 2013 18:10:34 +0200 Subject: [anti-abuse-wg] [db-wg] abuse-c + org In-Reply-To: <51CBF288.8000801@restena.lu> References: <51CBF288.8000801@restena.lu> Message-ID: <51D1A9FA.60009@ripe.net> [Apologies for duplicate emails.] Dear Gilles, These points were discussed on the Anti Abuse Working Group mailing lists quite extensively in June and December 2012. As you correctly pointed out policy ripe-563 says "This policy introduces a new contact attribute named "abuse-c:?, that can be included in inetnum, inet6num and aut-num objects." During the discussions last year it was asked if the RIPE NCC should 'interpret' policy. Our understanding is that this policy expresses the desire and goal of the RIPE community for a new feature in the RIPE Database. To achieve these goals this desire needs to be translated into, and incorporated in, an efficient, technical database design. In the RIPE Labs article https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06 we pointed out that there are about 3.7 million Internet resource objects in the RIPE Database. To add an "abuse-c:" attribute physically to each of these objects is unmanageable. Every users network is physically linked to their existing ORGANISATION object. Each user only needs to add one "abuse-c:" attribute in their ORGANISATION object and all their networks are covered. When any address is queried in the RIPE Database, the software will find the related "abuse-c:" reference and return this information as part of the query. By returning this information as a default with each query we have satisfied the policy requirement that the "abuse-c:" is "included in inetnum, inet6num and aut-num objects". It is not physically stored in each object in an unmanageable way, but logically associated with each object in an efficient and manageable way. This implementation was presented to and discussed by the community on the Anti Abuse Working Group mailing list last year and Brian declared that a consensus had been reached in his email on December 5, on behalf of the co-chairs of the DB and AA Working Groups: http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2012-December/001993.html In a follow up RIPE Labs article https://labs.ripe.net/Members/denis/creating-and-finding-abuse-contacts-in-the-ripe-database the RIPE NCC explained how this implementation works in practise. You may recall that we discussed the details of how these references using the ORGANISATION object worked and how they can be fine tuned: http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2012-December/001998.html The old RIPE Database reference manuals on the ripe.net web site still refer to the use of "abuse-mailbox:" attributes in other object types, but don't refer to "abuse-c:" at all. These attributes were never allowed to be added directly to the resource objects even in the legacy software. These old reference manuals are now out of date in many respects and should perhaps be clearly marked as archived documents. I hope this answers your specific questions. Regards Denis Walker Business Analyst RIPE NCC Database Team On 27/06/2013 10:06, Gilles Massen wrote: > Dear WG, and RIPE NCC staff, > > While trying to add an abuse-c to our resources, I was quite surprised > that you can only attach the abuse-c to an org object (while the policy > suggests otherwise and implementation notes are not very clear on the > limitation). > > So I'd like to ask why this restriction exists? What is wrong with > adding an abuse-c directly to an inet[6]num or aut-num? > > Best regards, > Gilles > From gilles.massen at restena.lu Tue Jul 2 11:28:31 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Tue, 02 Jul 2013 11:28:31 +0200 Subject: [anti-abuse-wg] [db-wg] abuse-c + org In-Reply-To: <51D1A9FA.60009@ripe.net> References: <51CBF288.8000801@restena.lu> <51D1A9FA.60009@ripe.net> Message-ID: <51D29D3F.4090608@restena.lu> Dear Denis, I think I did not make my concerns clear enough. While I'm not thrilled by the current aspect of abuse-c (esp. content limitations w.r.t. IRT) it is the current policy and I accept to live with that. What I was trying to point out is that the current implementation does not implement the policy correctly as it does not *allow* to attach an abuse-c to an inet[6]num or aut-num. The indirection via the ORGANISATION is fine and efficient, but constraining. My use case is to set a specific abuse-c for one autnum and inetnum, which is not the same as the general abuse-c of the organisation. Maybe I could create a 'fake' ORG in order to link to that (probably it would not work in my case), but that means data duplication. Allowing to attach the abuse-c to whatever object would solve it more nicely. The DBs query logic should hardly be affected as it is simply a matter of returning the most specific abuse-c for the object. > In the RIPE Labs article > https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06 > > we pointed out that there are about 3.7 million Internet resource > objects in the RIPE Database. To add an "abuse-c:" attribute > physically to each of these objects is unmanageable. Every users > network is physically linked to their existing ORGANISATION object. > Each user only needs to add one "abuse-c:" attribute in their > ORGANISATION object and all their networks are covered. Fully agree - it's probably the most efficient way to do it, but I see no reason for it to be the only one. > When any address is queried in the RIPE Database, the software will > find the related "abuse-c:" reference and return this information as > part of the query. By returning this information as a default with > each query we have satisfied the policy requirement that the > "abuse-c:" is "included in inetnum, inet6num and aut-num objects". Well, the policy is met in so far that all queries do return an abuse-c. However if I, the resource holder, can not chose accurately which one should be displayed the aim of the policy (having a good abuse-c) is missed. (and to be honest, returning real data in the 'comment' section of the result gives me the shivers) > This implementation was presented to and discussed by the community > on the Anti Abuse Working Group mailing list last year and Brian > declared that a consensus had been reached in his email on December > 5, on behalf of the co-chairs of the DB and AA Working Groups: > http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2012-December/001993.html I've > read that at the time (maybe not carefully enough) but is was never clear to me that the reference via the ORG object was the only way - I understood it as a complement to the obvious possibility of adding the contact to any object. > The old RIPE Database reference manuals on the ripe.net web site > still refer to the use of "abuse-mailbox:" attributes in other object > types, but don't refer to "abuse-c:" at all. These attributes were > never allowed to be added directly to the resource objects even in > the legacy software. These old reference manuals are now out of date > in many respects and should perhaps be clearly marked as archived > documents. By all means, please do so. There is nothing more confusion that slightly wrong documentation. Obviously an up to date documentation would be most welcome :) - at least a rough description of the objects with their fields (and the optional/mandatory nature of them). Best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From gert at space.net Tue Jul 2 13:47:46 2013 From: gert at space.net (Gert Doering) Date: Tue, 2 Jul 2013 13:47:46 +0200 Subject: [anti-abuse-wg] [db-wg] abuse-c + org In-Reply-To: <51D29D3F.4090608@restena.lu> References: <51CBF288.8000801@restena.lu> <51D1A9FA.60009@ripe.net> <51D29D3F.4090608@restena.lu> Message-ID: <20130702114746.GW2706@Space.Net> Hi, On Tue, Jul 02, 2013 at 11:28:31AM +0200, Gilles Massen wrote: > My use case is to set a specific abuse-c for one autnum and inetnum, > which is not the same as the general abuse-c of the organisation. Maybe > I could create a 'fake' ORG in order to link to that (probably it would > not work in my case), but that means data duplication. Allowing to > attach the abuse-c to whatever object would solve it more nicely. The > DBs query logic should hardly be affected as it is simply a matter of > returning the most specific abuse-c for the object. I seem to remember that I stated this as well, back then, and it was not seen as "important". So, yes, seconded. Gert Doering -- NetMaster -- have you enabled 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From stolpe at resilans.se Tue Jul 2 14:01:03 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Tue, 2 Jul 2013 14:01:03 +0200 (CEST) Subject: [anti-abuse-wg] [db-wg] abuse-c + org In-Reply-To: <20130702114746.GW2706@Space.Net> References: <51CBF288.8000801@restena.lu> <51D1A9FA.60009@ripe.net> <51D29D3F.4090608@restena.lu> <20130702114746.GW2706@Space.Net> Message-ID: On Tue, 2 Jul 2013, Gert Doering wrote: > Hi, > > On Tue, Jul 02, 2013 at 11:28:31AM +0200, Gilles Massen wrote: >> My use case is to set a specific abuse-c for one autnum and inetnum, >> which is not the same as the general abuse-c of the organisation. Maybe >> I could create a 'fake' ORG in order to link to that (probably it would >> not work in my case), but that means data duplication. Allowing to >> attach the abuse-c to whatever object would solve it more nicely. The >> DBs query logic should hardly be affected as it is simply a matter of >> returning the most specific abuse-c for the object. > > I seem to remember that I stated this as well, back then, and it was > not seen as "important". > > So, yes, seconded. There is alo a strange thing here: organisation: [mandatory] [single] [primary/lookup key] org-name: [mandatory] [single] [lookup key] org-type: [mandatory] [single] [ ] descr: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] geoloc: [optional] [single] [ ] language: [optional] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [optional] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] abuse-c: [optional] [single] [inverse key] ref-nfy: [optional] [multiple] [inverse key] mnt-ref: [mandatory] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [inverse key] <- mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Multiple abuse-mailboxes. role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] org: [optional] [multiple] [inverse key] admin-c: [optional] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/lookup key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] abuse-mailbox: [optional] [single] [inverse key] <- mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] One single. The one in "role" is the one that counts. Why don't we allow multiple addresses there? And yes. What it leads to is you have to create several org objects in order to get more than one (or different) abuse-mailboxes. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From rezaf at mindspring.com Tue Jul 2 18:10:33 2013 From: rezaf at mindspring.com (Reza Farzan) Date: Tue, 2 Jul 2013 12:10:33 -0400 (GMT-04:00) Subject: [anti-abuse-wg] Who owns 24.205.98.101? Message-ID: <16620961.1372781433989.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Hello Olaf, Yes, not a single response from Charter, and I am not surprised. Charter Communications [charter.net & charter.com] is one of those mega providers that does not respond to such questions. Their Contact Page, http://www.myaccount.charter.com/Customers/ContactUs.aspx, deals mainly with their customers and their related inquiries. But calling Charter's National Network Operations Center (+1-314-288-3111) could be the last option, if they actually answer that line. With countless servers and IPs, Charter may not be as responsive as we expect them to be. Thank you, Reza Farzan ++++++++++ -----Original Message----- >From: Olaf van der Spek >Sent: Jul 2, 2013 10:29 AM >To: Reza Farzan >Subject: Re: [anti-abuse-wg] Who owns 24.205.98.101? > >On Tue, Jun 25, 2013 at 4:07 PM, Reza Farzan wrote: >> Hello Peter, >> >> The Whois information clearly shows this IP to be part of Charter Communications network: >> >> NetRange: 24.205.76.0 - 24.205.99.255 >> CIDR: 24.205.96.0/22, 24.205.80.0/20, 24.205.76.0/22 >> OriginAS: >> NetName: CHAR-PAS-205-76-99 >> NetHandle: NET-24-205-76-0-1 >> Parent: NET-24-205-0-0-1 >> NetType: Reallocated >> RegDate: 2001-09-30 >> Updated: 2003-08-27 >> Ref: http://whois.arin.net/rest/net/NET-24-205-76-0-1 >> >> OrgName: Charter Communications >> OrgId: CC04 >> Address: 12405 Powerscourt Dr. >> City: St. Louis >> StateProv: MO >> PostalCode: 63131 >> Country: US >> RegDate: >> Updated: 2012-07-03 >> Ref: http://whois.arin.net/rest/org/CC04 >> >> OrgTechHandle: IPADD1-ARIN >> OrgTechName: IPAddressing >> OrgTechPhone: +1-314-288-3889 >> OrgTechEmail: ipaddressing at chartercom.com >> OrgTechRef: http://whois.arin.net/rest/poc/IPADD1-ARIN >> >> OrgAbuseHandle: ABUSE19-ARIN >> OrgAbuseName: Abuse >> OrgAbusePhone: +1-314-288-3111 >> OrgAbuseEmail: abuse at charter.net >> OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE19-ARIN >> >> OrgNOCHandle: NNOC16-ARIN >> OrgNOCName: National Network Operations Center >> OrgNOCPhone: +1-314-288-3111 >> OrgNOCEmail: dlnocip at chartercom.com >> OrgNOCRef: http://whois.arin.net/rest/poc/NNOC16-ARIN >> >> ++++ >> >> So, I do not understand why they are telling you otherwise. >> >> I have copied the responsible parties at Charter Communication so that they could investigate this matter further. ++++ Not a single response from Charter it seems. What's next? From peter at hk.ipsec.se Tue Jul 2 19:46:20 2013 From: peter at hk.ipsec.se (peter h) Date: Tue, 2 Jul 2013 19:46:20 +0200 Subject: [anti-abuse-wg] Who owns 24.205.98.101? In-Reply-To: <16620961.1372781433989.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> References: <16620961.1372781433989.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Message-ID: <201307021946.21258.peter@hk.ipsec.se> On Tuesday 02 July 2013 18.10, Reza Farzan wrote: > Hello Olaf, > > Yes, not a single response from Charter, and I am not surprised. > > Charter Communications [charter.net & charter.com] is one of those mega providers that does not respond to such questions. Their Contact Page, http://www.myaccount.charter.com/Customers/ContactUs.aspx, deals mainly with their customers and their related inquiries. > > But calling Charter's National Network Operations Center (+1-314-288-3111) could be the last option, if they actually answer that line. > > With countless servers and IPs, Charter may not be as responsive as we expect them to be. > > Thank you, > > Reza Farzan > > > ++++++++++ > > > -----Original Message----- > >From: Olaf van der Spek > >Sent: Jul 2, 2013 10:29 AM > >To: Reza Farzan > >Subject: Re: [anti-abuse-wg] Who owns 24.205.98.101? > > > >On Tue, Jun 25, 2013 at 4:07 PM, Reza Farzan wrote: > >> Hello Peter, > >> > >> The Whois information clearly shows this IP to be part of Charter Communications network: > >> > >> NetRange: 24.205.76.0 - 24.205.99.255 > >> CIDR: 24.205.96.0/22, 24.205.80.0/20, 24.205.76.0/22 > >> OriginAS: > >> NetName: CHAR-PAS-205-76-99 > >> NetHandle: NET-24-205-76-0-1 > >> Parent: NET-24-205-0-0-1 > >> NetType: Reallocated > >> RegDate: 2001-09-30 > >> Updated: 2003-08-27 > >> Ref: http://whois.arin.net/rest/net/NET-24-205-76-0-1 > >> > >> OrgName: Charter Communications > >> OrgId: CC04 > >> Address: 12405 Powerscourt Dr. > >> City: St. Louis > >> StateProv: MO > >> PostalCode: 63131 > >> Country: US > >> RegDate: > >> Updated: 2012-07-03 > >> Ref: http://whois.arin.net/rest/org/CC04 > >> > >> OrgTechHandle: IPADD1-ARIN > >> OrgTechName: IPAddressing > >> OrgTechPhone: +1-314-288-3889 > >> OrgTechEmail: ipaddressing at chartercom.com > >> OrgTechRef: http://whois.arin.net/rest/poc/IPADD1-ARIN > >> > >> OrgAbuseHandle: ABUSE19-ARIN > >> OrgAbuseName: Abuse > >> OrgAbusePhone: +1-314-288-3111 > >> OrgAbuseEmail: abuse at charter.net > >> OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE19-ARIN > >> > >> OrgNOCHandle: NNOC16-ARIN > >> OrgNOCName: National Network Operations Center > >> OrgNOCPhone: +1-314-288-3111 > >> OrgNOCEmail: dlnocip at chartercom.com > >> OrgNOCRef: http://whois.arin.net/rest/poc/NNOC16-ARIN > >> > >> ++++ > >> > >> So, I do not understand why they are telling you otherwise. > >> > >> I have copied the responsible parties at Charter Communication so that they could investigate this matter further. > > ++++ > > Not a single response from Charter it seems. What's next? Block from access. That's the only thing that will keep those beasts from your net. (sorbs already blocks that net ) > > > -- Peter H?kanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det ?r billigare att g?ra r?tt. Det ?r dyrt att laga fel. ) From tk at abusix.com Tue Jul 2 19:47:07 2013 From: tk at abusix.com (Tobias Knecht) Date: Tue, 02 Jul 2013 10:47:07 -0700 Subject: [anti-abuse-wg] [db-wg] abuse-c + org In-Reply-To: <51D29D3F.4090608@restena.lu> References: <51CBF288.8000801@restena.lu> <51D1A9FA.60009@ripe.net> <51D29D3F.4090608@restena.lu> Message-ID: <51D3121B.20703@abusix.com> Hi, > What I was trying to point out is that the current implementation does > not implement the policy correctly as it does not *allow* to attach an > abuse-c to an inet[6]num or aut-num. The indirection via the > ORGANISATION is fine and efficient, but constraining. That was in some ways wanted that way. The biggest challenge was to find a way that makes 100% sure that there will be no way to what so ever it will be to start creating a new mess in the RIPE DB. So we had to keep very strict. We figured out that people and even we ourselves tend to underestimate the risk of deigning something that end up messy. If we allow direct multiple references and multiply org references we would end up in a mess again. So since I was the proposer of the policy, the implementation impact showed me that this indirect allocation over ORG is a much better way. That's why I agreed on this way and it was reached consensus. One of the main goals imho of the RIPE DB has to be not ending up in a mess. Because this leads to a unusable DB. > My use case is to set a specific abuse-c for one autnum and inetnum, > which is not the same as the general abuse-c of the organisation. Maybe > I could create a 'fake' ORG in order to link to that (probably it would > not work in my case), but that means data duplication. Allowing to > attach the abuse-c to whatever object would solve it more nicely. The > DBs query logic should hardly be affected as it is simply a matter of > returning the most specific abuse-c for the object. Having an abuse-c referenced in an asn-num is a "relict" from one of the first proposals I wrote. And I'm fully responsible for forgetting about this issue. I'm at the moment wondering if there is really a need to have an abuse-c referenced by an aut-num. After the transition phase we should end up with an abuse-c for every single ip-address. So is it necessary? I know it can be helpful if an LIR does not want to react or handle complaints we would have a chance that the aut-num is doing something. But if he is not doing something we need to have another route to go, which is already in discussion. So do we really need an abuse-c referenced in aut-nums? And sorry again, this was my fault not being patience enough with my own policy text. > Fully agree - it's probably the most efficient way to do it, but I see > no reason for it to be the only one. There is. As described above if we allow direct multiple references and multiply org references we would end up in a mess again. > Well, the policy is met in so far that all queries do return an abuse-c. > However if I, the resource holder, can not chose accurately which one > should be displayed the aim of the policy (having a good abuse-c) is missed. You can in regards of all inet(6)nums. You just have to use ORGs. > (and to be honest, returning real data in the 'comment' section of the > result gives me the shivers) brrrrrr :-) No please don't do that. :-) I was already talking to some people and tried to find a way to solve your requests. We are working on it. Thanks, Tobias -- AA-WG Chair From gilles.massen at restena.lu Tue Jul 2 22:40:18 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Tue, 02 Jul 2013 22:40:18 +0200 Subject: [anti-abuse-wg] [db-wg] abuse-c + org In-Reply-To: <51D3121B.20703@abusix.com> References: <51CBF288.8000801@restena.lu> <51D1A9FA.60009@ripe.net> <51D29D3F.4090608@restena.lu> <51D3121B.20703@abusix.com> Message-ID: <51D33AB2.1010904@restena.lu> Hi Tobias, >> What I was trying to point out is that the current implementation >> does not implement the policy correctly as it does not *allow* to >> attach an abuse-c to an inet[6]num or aut-num. The indirection via >> the ORGANISATION is fine and efficient, but constraining. > > That was in some ways wanted that way. > > The biggest challenge was to find a way that makes 100% sure that > there will be no way to what so ever it will be to start creating a > new mess in the RIPE DB. So we had to keep very strict. You are quite optimistic :) You cannot design anything foolproof - fools are much too inventive. :) > If we allow direct multiple references and multiply org references we > would end up in a mess again. I can see why you wouldn't want multiple references but I don't buy that a direct reference would create a mess. The concept of 'more specific' should be somewhat obvious to this community. > So since I was the proposer of the policy, the implementation impact > showed me that this indirect allocation over ORG is a much better > way. That's why I agreed on this way and it was reached consensus. I wouldn't want to challenge the policy process based on my inattention, but considering that the policy text explicitely mentions inetnum and aut-num, I never understood the proposed implementation as the only way, only as a facilitating workaround to inetnum-referenced abuse-c. But that's probably only me... > One of the main goals imho of the RIPE DB has to be not ending up in > a mess. Because this leads to a unusable DB. I think the main goal of the RIPE DB is to serve the data that the data provider wants to be served. > Having an abuse-c referenced in an asn-num is a "relict" from one of > the first proposals I wrote. And I'm fully responsible for > forgetting about this issue. > > I'm at the moment wondering if there is really a need to have an > abuse-c referenced by an aut-num. After the transition phase we > should end up with an abuse-c for every single ip-address. So is it > necessary? Frankly: unsure. But in a setup with anycasted IP addresses, maybe different addresses served by different ASs, I can imagine a situation were it would be useful. >> Fully agree - it's probably the most efficient way to do it, but I >> see no reason for it to be the only one. > > There is. As described above if we allow direct multiple references > and multiply org references we would end up in a mess again. As I said: not multiple references, only more specific. >> Well, the policy is met in so far that all queries do return an >> abuse-c. However if I, the resource holder, can not chose >> accurately which one should be displayed the aim of the policy >> (having a good abuse-c) is missed. > > You can in regards of all inet(6)nums. You just have to use ORGs. In theory yes, but as the ORG is the same, only the abuse handler different that would mean creating an duplicate of the ORG for the sole purpose of referencing a different abuse-c. There is a lot potential for creating a mess in that workaround. (and one of the use cases I have in mind is a direct anycast assignment - not even sure that I'm allowed to do that) More generically I could also imagine having a different abuse handler for, say, dynamic DSL ranges than for web hosting: having an efficient abuse handling is obviously also in the interest of the submitter. >> (and to be honest, returning real data in the 'comment' section of >> the result gives me the shivers) > > brrrrrr :-) No please don't do that. :-) Like: % Abuse contact for '193.0.0.0 - 193.0.7.255' is 'abuse at ripe.net' ? :) > I was already talking to some people and tried to find a way to solve > your requests. We are working on it. One thing that annoys me in this is that the implementation does not match the (my?) understanding of the policy text. Whatever the outcome of this discussion is, I would welcome if they were more aligned (and yes, I know that the boundaries between policy and implementation are not always clearly cut). Best, Gilles From pk at DENIC.DE Wed Jul 3 08:48:25 2013 From: pk at DENIC.DE (Peter Koch) Date: Wed, 3 Jul 2013 08:48:25 +0200 Subject: [anti-abuse-wg] [db-wg] abuse-c + org In-Reply-To: <51D33AB2.1010904@restena.lu> References: <51CBF288.8000801@restena.lu> <51D1A9FA.60009@ripe.net> <51D29D3F.4090608@restena.lu> <51D3121B.20703@abusix.com> <51D33AB2.1010904@restena.lu> Message-ID: <20130703064825.GY26349@x28.adm.denic.de> On Tue, Jul 02, 2013 at 10:40:18PM +0200, Gilles Massen wrote: > I wouldn't want to challenge the policy process based on my inattention, > but considering that the policy text explicitely mentions inetnum and > aut-num, I never understood the proposed implementation as the only way, > only as a facilitating workaround to inetnum-referenced abuse-c. But > that's probably only me... no -Peter From tk at abusix.com Wed Jul 3 17:50:49 2013 From: tk at abusix.com (Tobias Knecht) Date: Wed, 03 Jul 2013 08:50:49 -0700 Subject: [anti-abuse-wg] [db-wg] abuse-c + org In-Reply-To: <51D33AB2.1010904@restena.lu> References: <51CBF288.8000801@restena.lu> <51D1A9FA.60009@ripe.net> <51D29D3F.4090608@restena.lu> <51D3121B.20703@abusix.com> <51D33AB2.1010904@restena.lu> Message-ID: <51D44859.8060908@abusix.com> Hi Gilles, > You are quite optimistic :) You cannot design anything foolproof - fools > are much too inventive. :) That is true and that was never the intend. But we tried to have something that can be checked with rules to find the fools. :-) > I can see why you wouldn't want multiple references but I don't buy that > a direct reference would create a mess. The concept of 'more specific' > should be somewhat obvious to this community. We would end up in some cases having 2 or more possibly different abuse-c objects for 1 resource. > I think the main goal of the RIPE DB is to serve the data that the data > provider wants to be served. I think I have to slightly disagree here. :-) If every data provider can put whatever he wants in the DB ... There are rules and these rules are usually policies. BUT the policies proposal process is a process that has the right to change policy texts while discussion is going on. And yes we or better I made the mistake to not adjust the policy text at the end completely to what the implementation process was. BUT never the less the policy as is worked for the majority of people otherwise it would not have been consensus called by Brian. > Frankly: unsure. But in a setup with anycasted IP addresses, maybe > different addresses served by different ASs, I can imagine a situation > were it would be useful. Maybe this is something we have to discuss further more. >>> Fully agree - it's probably the most efficient way to do it, but I >>> see no reason for it to be the only one. >> There is. As described above if we allow direct multiple references >> and multiply org references we would end up in a mess again. > > As I said: not multiple references, only more specific. You can be as specific as you want to be. you just have to go the way over the ORG. I'm not 100% but I think the ORG might be a bit misleading here. ORG doesn't mean a company. It can be different divisions of an Organisation. > In theory yes, but as the ORG is the same, only the abuse handler > different that would mean creating an duplicate of the ORG for the sole > purpose of referencing a different abuse-c. There is a lot potential for > creating a mess in that workaround. (and one of the use cases I have in > mind is a direct anycast assignment - not even sure that I'm allowed to > do that) > > More generically I could also imagine having a different abuse handler > for, say, dynamic DSL ranges than for web hosting: having an efficient > abuse handling is obviously also in the interest of the submitter. To be honest I'm not sure either with the anycast assignments. As already mentioned: ORG is not a company. It can be a division of a company. So if you are talking about dynamic DSL ranges and hosting ranges, you can create an ORG for Hosting and DSL. In future, when you add new resources or change stuff in the abuse-c you will have to change it at one single point. and not in all ranges. So this leads to a much easier way of maintaining it. Yes the pain now will be bigger until everybody has build up the new structure and has it in place. >> I was already talking to some people and tried to find a way to solve >> your requests. We are working on it. > > One thing that annoys me in this is that the implementation does not > match the (my?) understanding of the policy text. Whatever the outcome > of this discussion is, I would welcome if they were more aligned (and > yes, I know that the boundaries between policy and implementation are > not always clearly cut). As mentioned, my fault. I will check if we can change the policy text in a few points to match the real world plan we have agreed on as a policy. Otherwise, there will be some more policy proposals coming up soon so maybe we have the chance to get things straitened out a bit. Sorry again for that. Thanks, Tobias From gert at space.net Wed Jul 3 19:41:52 2013 From: gert at space.net (Gert Doering) Date: Wed, 3 Jul 2013 19:41:52 +0200 Subject: [anti-abuse-wg] [db-wg] abuse-c + org In-Reply-To: <51D44859.8060908@abusix.com> References: <51CBF288.8000801@restena.lu> <51D1A9FA.60009@ripe.net> <51D29D3F.4090608@restena.lu> <51D3121B.20703@abusix.com> <51D33AB2.1010904@restena.lu> <51D44859.8060908@abusix.com> Message-ID: <20130703174152.GS2706@Space.Net> Hi, On Wed, Jul 03, 2013 at 08:50:49AM -0700, Tobias Knecht wrote: > So if you are talking about dynamic DSL ranges and hosting ranges, you > can create an ORG for Hosting and DSL. In future, when you add new > resources or change stuff in the abuse-c you will have to change it at > one single point. and not in all ranges. So this leads to a much easier > way of maintaining it. Yes the pain now will be bigger until everybody > has build up the new structure and has it in place. If I want to change stuff "in the abuse-c", I change it "in the abuse-c", so that argument just doesn't hold. This indirection, always using an org, is nice from a computer science and database design point of view, but if you want people to *accept* and *use* what you give them, you should design something that people like to use. I find the idea quite useful, and adding a single object (abuse-c) for a single purpose is perfectly fine, but having to add extra objects just to fulfill synthetic constraints is annoying me, so I don't do it, and the quality of the abuse-c: is not as good as it could be (because I don't bother to add more detailed information). So, how exactly did anyone benefit from this "must have org!" constraint? (And for the argument "it wouldn't be clear, then, which one takes precedence" - that's easy: document it - and it's quite obvious to anyone but a computer scientist, I'd say - "if there is an abuse-c:, take that one, if not, take the org:, if neither, go less specific and repeat") Gert Doering -- NetMaster -- have you enabled 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From lhcarrara at gmail.com Wed Jul 3 19:38:01 2013 From: lhcarrara at gmail.com (lhcarrara at gmail.com) Date: Wed, 3 Jul 2013 14:38:01 -0300 Subject: [anti-abuse-wg] Sending SPAM Message-ID: Hello friends. Not sure this is the correct channel, if there is some other form of contact, but I do not see how else to complain about, I'm trying all possibilities. This message is translated by Google Translator. So excuse me if there are any errors. Well, I'm having problems with SPAM from provider OVH. I have received several of them in recent weeks, but not when I am finding solution complaints. When I started to complain to the email abuse at ovh.net (that does not work, even), and then the e-mail suporte at ovh.net, the operator asked me to get in touch directly with the email abuse that listed in the register of IP RIPE.NET. It is what I have done. But in recent days, the customer who owns the OVH email spam-control at hospedagemgenial.com.br been sending me various SPAM. But this email ( spam-control at hospedagemgenial.com.br) does not exist, so my complaints are not enough. So, I began to denounce the SPAM directly to OVH, but nothing was done. I keep getting these SPAM. I do not know if they do not have infrastructure to filter it, or do not want to block the account of spamming, but keep getting the messages. To my enchegar things, when a carrier sells a framework for sending emails advertising (fancy name for SPAM), it is also responsible for such transmission. I did not ask her client (the spam-control at hospedagemgenial.com.br) send me SPAM. These customers simply take our e-mail who knows where and start sending us spam. And when we complained, the provider does nothing. I can not stand staying receiving such messages, do not want to receive and do not want to be made a fool by clicking on "click here to unsubscribe" because I know I'll keep getting spam from the same company, only one other product. Wish you could help me make a formal complaint about the sending of SPAM opereradora OVH or, if not the responsibility of you, if you could show me how it should be done. Thank you for your attention. Henrique -------------- next part -------------- An HTML attachment was scrubbed... URL: From tk at abusix.com Wed Jul 3 22:28:52 2013 From: tk at abusix.com (Tobias Knecht) Date: Wed, 03 Jul 2013 13:28:52 -0700 Subject: [anti-abuse-wg] [db-wg] abuse-c + org In-Reply-To: <20130703174152.GS2706@Space.Net> References: <51CBF288.8000801@restena.lu> <51D1A9FA.60009@ripe.net> <51D29D3F.4090608@restena.lu> <51D3121B.20703@abusix.com> <51D33AB2.1010904@restena.lu> <51D44859.8060908@abusix.com> <20130703174152.GS2706@Space.Net> Message-ID: <51D48984.4060807@abusix.com> Hello, > If I want to change stuff "in the abuse-c", I change it "in the abuse-c", > so that argument just doesn't hold. There are members that have just a few more resources than others and possibly a much more complicated structure. The new way is generalized and by this easier to maintain and more flexible without destroying structure. > This indirection, always using an org, is nice from a computer science > and database design point of view, but if you want people to *accept* and > *use* what you give them, you should design something that people like > to use. There were a few phases in the policy proposal process where exactly this could have happened. It did not! There have been a few cases which have been discussed on the mailing list and after all we asked for feedback of all people that brought up concerns if they are happy with the way we tried to solve them. The majority has been happy with it. Overall I got extremely good feedback from members in Dublin. Even the numbers tell us that it's not that people do not like the new way. Of course there will always be some that do not like it, but that's why this is a community and a democratic process. > I find the idea quite useful, and adding a single object (abuse-c) for > a single purpose is perfectly fine, but having to add extra objects > just to fulfill synthetic constraints is annoying me, so I don't do > it, and the quality of the abuse-c: is not as good as it could be > (because I don't bother to add more detailed information). The intend was to put real life scenarios into database. You usually always have resources given to organizations. If it's different teams within a company or if it's business customers having their own ranges doesn't matter. Even both is easily doable with the new structure. The new structure seems in the first step a bit more complicated, but makes things so much easier over time. That's what I heard a lot from people by talking to them in Dublin. Funny enough a lot of members were already asking me why we are not doing the same with admin-c and tech-c. Not updating will lead into an automatic update by RIPE NCC. Data accuracy is another part we are working on at the moment. There will be some ideas coming up on the mailing list before Athens in October. We already have some ideas in mind, but I'd rather listen to the community discussion happening at the moment and figure out that we not missed something. > So, how exactly did anyone benefit from this "must have org!" constraint? For huge organizations it's getting easier to manage and update their huge amounts of resources. For very small organizations it is very easy, because they have one single place to organize their objects. Easy to have everything setup in the same way. Easy to split and not getting confused. Midsize companies can maybe profit from both. And if somebody not benefiting from any of these things - I'm sorry. And as already mentioned: Majority of people I talked to like it a lot. > (And for the argument "it wouldn't be clear, then, which one takes > precedence" - that's easy: document it - and it's quite obvious to anyone > but a computer scientist, I'd say - "if there is an abuse-c:, take that > one, if not, take the org:, if neither, go less specific and repeat") I guess that would have been possible. But we (Proposer, Task Force, RIPE NCC DB Team, several WG Chairs, ...) didn't decide this way. We always communicated that this is only a first step of what we have on our agenda (Further clean up, data accuracy, ...). So I guess there will some thing coming up that make things more clear and some others that create different confusion again. Never the less our aim is to be as open as possible, what we always tried and try to be. So if there are further questions, concerns or ideas please let us know and we will do our best to answer them or take them in considerations and discuss them any further. Thanks, Tobias -- AA-WG Chair From gilles.massen at restena.lu Wed Jul 3 22:53:13 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Wed, 03 Jul 2013 22:53:13 +0200 Subject: [anti-abuse-wg] [db-wg] abuse-c + org In-Reply-To: <51D44859.8060908@abusix.com> References: <51CBF288.8000801@restena.lu> <51D1A9FA.60009@ripe.net> <51D29D3F.4090608@restena.lu> <51D3121B.20703@abusix.com> <51D33AB2.1010904@restena.lu> <51D44859.8060908@abusix.com> Message-ID: <51D48F39.7040609@restena.lu> Hi Tobias, >> I can see why you wouldn't want multiple references but I don't buy >> that a direct reference would create a mess. The concept of 'more >> specific' should be somewhat obvious to this community. > > We would end up in some cases having 2 or more possibly different > abuse-c objects for 1 resource. Exactly as we have now: if a resource has, besides the LIR, an organisation object with abuse-c, you do have 2 covering abuse-c object (as the one for the 'customer' org is optional). >> I think the main goal of the RIPE DB is to serve the data that the >> data provider wants to be served. > > I think I have to slightly disagree here. :-) If every data provider > can put whatever he wants in the DB ... Correct... but as Gert pointed out: if you make it difficult for the data provider to be accurate (within the rules), he won't. And it's a loss to everyone. After all, providing accurate data via the RIPE DB is more a service to the community than a revenue generating action. > BUT never the less the policy as is worked for the majority of > people otherwise it would not have been consensus called by Brian. Well, the mail said 'no objections' - and that's correct. But if the absence of objections is based on a misunderstanding of the implementation (because the restrictions were not spelled out) the consensus is pretty worthless. As I can obviously only speak for myself, I'd love to hear from others if it was clear to them that an abuse-c could ONLY be linked to an organisation. > You can be as specific as you want to be. you just have to go the > way over the ORG. I'm not 100% but I think the ORG might be a bit > misleading here. ORG doesn't mean a company. It can be different > divisions of an Organisation. >From the reference manual about organisation: "This entity may be a company, non profit group or individual.". Besides, if you would create a division as the referenced org of an inetnum, you would lose (or make it hard to find) the information 'what resources does this org have?' And I'd consider that as a loss. > So if you are talking about dynamic DSL ranges and hosting ranges, > you can create an ORG for Hosting and DSL. In future, when you add > new resources or change stuff in the abuse-c you will have to change > it at one single point. and not in all ranges. So this leads to a > much easier way of maintaining it. Yes the pain now will be bigger > until everybody has build up the new structure and has it in place. One point of the organisation construct was to lessen the pain, wasn't it? But at the end of the day all your arguments are in favor of having the organisation construct (and I agree). It certainly suits the majority. However none of them convinces me that allowing references from the resource objects is actually bad. I just don't see anyone using it unless he sees a need...and having accurate abuse-c is, after all, a goal of the AA WG and the abuse-c policy. > I will check if we can change the policy text > in a few points to match the real world plan we have agreed on as a > policy. I strongly object to that conception: only the policy is policy. Even if the implementation is confirmed (or non-objected) by the WGs, it cannot modify, enhance or restrict the initial policy. Best, Gilles From ripe-anti-spam-wg at powerweb.de Thu Jul 4 08:42:00 2013 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Thu, 04 Jul 2013 08:42:00 +0200 Subject: [anti-abuse-wg] Sending SPAM In-Reply-To: References: Message-ID: <51D51938.8050100@powerweb.de> lhcarrara at gmail.com wrote: > > Well, I'm having problems with SPAM from provider OVH. OVH is known to us for ignoring abuse reports and also known here not to invest a lot of work in cleaning their networks. Dont waste your time with them, blacklist their IPs and your done. Kind regards, Frank > I have received > several of them in recent weeks, but not when I am finding solution > complaints. When I started to complain to the email abuse at ovh.net > (that does not work, even), and then the e-mail > suporte at ovh.net , the operator asked me to get > in touch directly with the email abuse that listed in the register of IP > RIPE.NET . It is what I have done. But in recent days, > the customer who owns the OVH email spam-control at hospedagemgenial.com.br > been sending me various > SPAM. But this email (spam-control at hospedagemgenial.com.br > ) does not exist, so my > complaints are not enough. So, I began to denounce the SPAM directly to > OVH, but nothing was done. I keep getting these SPAM. I do not know if > they do not have infrastructure to filter it, or do not want to block > the account of spamming, but keep getting the messages. > To my enchegar things, when a carrier sells a framework for sending > emails advertising (fancy name for SPAM), it is also responsible for > such transmission. I did not ask her client (the > spam-control at hospedagemgenial.com.br > ) send me SPAM. These > customers simply take our e-mail who knows where and start sending us > spam. And when we complained, the provider does nothing. > I can not stand staying receiving such messages, do not want to receive > and do not want to be made a fool by clicking on "click here to > unsubscribe" because I know I'll keep getting spam from the same > company, only one other product. > Wish you could help me make a formal complaint about the sending of SPAM > opereradora OVH or, if not the responsibility of you, if you could show > me how it should be done. > Thank you for your attention. > Henrique -- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== From niall.oreilly at ucd.ie Thu Jul 4 11:31:38 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Thu, 4 Jul 2013 10:31:38 +0100 Subject: [anti-abuse-wg] [db-wg] abuse-c + org In-Reply-To: <51D48F39.7040609@restena.lu> References: <51CBF288.8000801@restena.lu> <51D1A9FA.60009@ripe.net> <51D29D3F.4090608@restena.lu> <51D3121B.20703@abusix.com> <51D33AB2.1010904@restena.lu> <51D44859.8060908@abusix.com> <51D48F39.7040609@restena.lu> Message-ID: On 3 Jul 2013, at 21:53, Gilles Massen wrote: > Well, the mail said 'no objections' - and that's correct. But if the > absence of objections is based on a misunderstanding of the > implementation (because the restrictions were not spelled out) the > consensus is pretty worthless. +1 > As I can obviously only speak for myself, > I'd love to hear from others if it was clear to them that an abuse-c > could ONLY be linked to an organisation. This wasn't clear to me either. ATB Niall From ripencc-management at ripe.net Thu Jul 4 15:31:26 2013 From: ripencc-management at ripe.net (Andrew de la Haye) Date: Thu, 4 Jul 2013 15:31:26 +0200 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits Message-ID: Dear colleagues, We have been following the recent discussions on the mailing list and would like to offer clarification in relation to a couple of points that were raised. According to "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" [1], address space is distributed based on demonstrated technical need in order to deliver services. This need is evaluated according to addressing requirements, network infrastructure, equipment and number of customers. The exact services for which the resources are being requested are not considered as part of the evaluation process. As an example, if address space is requested for the technical need of a mail server, it is not verified what type of mails are being sent through that server. This practice is in line with the current IPv4 policy [1]. It is important to note that technical need is evaluated for assignments. The need for an additional allocation is considered based on past and future usage, taking into account all assignments that have been made by the LIR previously. The RIPE NCC does not have a mandate to deregister allocations if the expected growth was less or different than expected. Nevertheless, we do see LIRs voluntarily returning allocations in the event that they no longer have a need for the addresses. As above, this practice is based on current RIPE Policies. When a policy is changed through the RIPE Policy Development Process (PDP) [2], we adjust our processes accordingly. When the RIPE NCC conducts an audit of an LIR, it checks that: - RIPE Policies are followed correctly - Assignments are registered properly and being used for the purpose they were requested for (if not, the technical need is re-evaluated) - Contact information is still correct An LIR is either randomly selected for an audit, or selected following a community report against that member [3]. Last year, the RIPE NCC created a report form to facilitate and simplify reporting on policy violations, provision of untruthful information to the RIPE NCC and incorrect RIPE Database data [4]. Once the reported information and evidence is evaluated, the RIPE NCC investigates the claim and proceeds according to RIPE Policies and RIPE NCC procedures. This can result in address space being deregistered. More detailed information on reasons for deregistration of address space is available in "Closure of Member and Deregistration of Internet Number Resources" [5]. Kind regards Andrew de la Haye Chief Operations Officer RIPE NCC [1] "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" http://www.ripe.net/ripe/docs/v4policy [2] "RIPE Policy Development" http://www.ripe.net/ripe/policies [3] "RIPE NCC Audit Activity" http://www.ripe.net/ripe/docs/audit [4] "RIPE NCC Reporting Procedure" http://www.ripe.net/contact/ripe-ncc-complaints-procedure [5] "Closure of Member and Deregistration of Internet Number Resources" http://www.ripe.net/ripe/docs/closure -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Thu Jul 4 15:41:46 2013 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 04 Jul 2013 15:41:46 +0200 Subject: [anti-abuse-wg] New on RIPE Labs: Geoff Huston - Here's Looking At You.. Message-ID: <51D57B9A.4000506@ripe.net> [apologies for duplicates] Dear colleagues, Geoff Huston measured to what extent information relating to individuals? activities online is being passed to others. Please see his findings on RIPE Labs: https://labs.ripe.net/Members/gih/heres-looking-at-you Kind regards, Mirjam Kuehne RIPE NCC From ripe-anti-spam-wg at powerweb.de Thu Jul 4 16:52:14 2013 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Thu, 04 Jul 2013 16:52:14 +0200 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits In-Reply-To: References: Message-ID: <51D58C1E.6070100@powerweb.de> Andrew de la Haye wrote: Hello, > ... The exact services for which the > resources are being requested are not considered as part of the > evaluation process. As an example, if address space is requested for the > technical need of a mail server, it is not verified what type of mails > are being sent through that server. > ... > - Assignments are registered properly and being used for the purpose > they were requested for (if not, the technical need is re-evaluated) These two points interest me the most. Lets say, an LIR is requesting IPs for the purpose of access, but then runs mailservers on it, sending lots of spam. - first, how do you find evidence, that the LIR is using the address space now for a different purpose ? - second, did it ever happen, that the NCC revoked address space or allocations or terminated a contract, because the LIR was using the IPs for a different purpose and then denied fix that ? Kind regards, Frank > > Kind regards > > Andrew de la Haye > Chief Operations Officer > RIPE NCC > > [1] "IPv4 Address Allocation and Assignment Policies for the RIPE NCC > Service Region" > http://www.ripe.net/ripe/docs/v4policy > > [2] "RIPE Policy Development" > http://www.ripe.net/ripe/policies > > [3] "RIPE NCC Audit Activity" > http://www.ripe.net/ripe/docs/audit > > [4] "RIPE NCC Reporting Procedure" > http://www.ripe.net/contact/ripe-ncc-complaints-procedure > > [5] "Closure of Member and Deregistration of Internet Number Resources" > http://www.ripe.net/ripe/docs/closure From gert at space.net Thu Jul 4 16:56:50 2013 From: gert at space.net (Gert Doering) Date: Thu, 4 Jul 2013 16:56:50 +0200 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits In-Reply-To: <51D58C1E.6070100@powerweb.de> References: <51D58C1E.6070100@powerweb.de> Message-ID: <20130704145650.GZ2706@Space.Net> Hi, On Thu, Jul 04, 2013 at 04:52:14PM +0200, Frank Gadegast wrote: > > ... The exact services for which the > > resources are being requested are not considered as part of the > > evaluation process. As an example, if address space is requested for the > > technical need of a mail server, it is not verified what type of mails > > are being sent through that server. > > ... > > - Assignments are registered properly and being used for the purpose > > they were requested for (if not, the technical need is re-evaluated) > > These two points interest me the most. > Lets say, an LIR is requesting IPs for the purpose of access, > but then runs mailservers on it, sending lots of spam. You're mixing "allocation" and "assignment". The LIR requests an *allocation*, which is not bound to a specific purpose. The end user (which might be the LIR itself, but usually is "a customer of the LIR") receives an *assignment*, which comes with a technical need. Gert Doering -- NetMaster -- have you enabled 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From ripe-anti-spam-wg at powerweb.de Thu Jul 4 17:16:05 2013 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Thu, 04 Jul 2013 17:16:05 +0200 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits In-Reply-To: <20130704145650.GZ2706@Space.Net> References: <51D58C1E.6070100@powerweb.de> <20130704145650.GZ2706@Space.Net> Message-ID: <51D591B5.9090503@powerweb.de> Gert Doering wrote: > Hi, > > On Thu, Jul 04, 2013 at 04:52:14PM +0200, Frank Gadegast wrote: >>> ... The exact services for which the >>> resources are being requested are not considered as part of the >>> evaluation process. As an example, if address space is requested for the >>> technical need of a mail server, it is not verified what type of mails >>> are being sent through that server. >>> ... >>> - Assignments are registered properly and being used for the purpose >>> they were requested for (if not, the technical need is re-evaluated) >> >> These two points interest me the most. >> Lets say, an LIR is requesting IPs for the purpose of access, >> but then runs mailservers on it, sending lots of spam. > > You're mixing "allocation" and "assignment". The LIR requests an > *allocation*, which is not bound to a specific purpose. Im mixing nothing here. You need to specify a purpose for any assignment you make from your allocation, internally or directly to the NCC. And the purpose seems to be re-evaluated when there is an audit started. So the two questions remain: - first, how do you find evidence, that the LIR is using the address space now for a different purpose ? - second, did it ever happen, that the NCC revoked address space or allocations or terminated a contract, because the LIR was using the IPs for a different purpose and then denied fix that ? I could have written here "assignments or allocations or terminated" ... > The end user (which might be the LIR itself, but usually is "a customer > of the LIR") receives an *assignment*, which comes with a technical > need. Did not say anything different. Pointing to a possible failure in my wording just stops others in answering important questions (what happens a lot lately), simply because its interupting "the flow" ;o) Its important to know, how the community can help starting an audit process with the goal to revoke some address space that is obviously used for massive abuse. We need to know, how to start this process (e.g. where is this form ?), what to proove, how to give evidence aso and how the NCC handles this. Simply because it seems to be the only mossible procedure to revoke address space, when its not used for its initial purpose anymore. And I really like to have an answer from the NCC about all this. Kind regards, Frank > > Gert Doering > -- NetMaster > From gert at space.net Thu Jul 4 17:31:25 2013 From: gert at space.net (Gert Doering) Date: Thu, 4 Jul 2013 17:31:25 +0200 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits In-Reply-To: <51D591B5.9090503@powerweb.de> References: <51D58C1E.6070100@powerweb.de> <20130704145650.GZ2706@Space.Net> <51D591B5.9090503@powerweb.de> Message-ID: <20130704153125.GB2706@Space.Net> Hi, On Thu, Jul 04, 2013 at 05:16:05PM +0200, Frank Gadegast wrote: > Gert Doering wrote: > > On Thu, Jul 04, 2013 at 04:52:14PM +0200, Frank Gadegast wrote: > >>> ... The exact services for which the > >>> resources are being requested are not considered as part of the > >>> evaluation process. As an example, if address space is requested for the > >>> technical need of a mail server, it is not verified what type of mails > >>> are being sent through that server. > >>> ... > >>> - Assignments are registered properly and being used for the purpose > >>> they were requested for (if not, the technical need is re-evaluated) > >> > >> These two points interest me the most. > >> Lets say, an LIR is requesting IPs for the purpose of access, > >> but then runs mailservers on it, sending lots of spam. > > > > You're mixing "allocation" and "assignment". The LIR requests an > > *allocation*, which is not bound to a specific purpose. > > Im mixing nothing here. > You need to specify a purpose for any assignment you make from > your allocation, internally or directly to the NCC. If you write "the LIR is requesting IPs for the purpose of access", you're mixing up things. LIRs request IP addresses to give them to customers. Not for particular uses. > And the purpose seems to be re-evaluated when there is an audit > started. Read again what Andrew wrote, and keep in mind the difference between "allocation" and "assignment". > So the two questions remain: > > - first, how do you find evidence, that the LIR is using the > address space now for a different purpose ? As the *LIR* did not specify a purpose, it can't be "a different purpose" now. > - second, did it ever happen, that the NCC revoked address > space or allocations or terminated a contract, because the > LIR was using the IPs for a different purpose and then denied > fix that ? No, because that situation can not happen. The LIR does not specify a purpose, so there is no way they could be used for a "different purpose". [..] > Pointing to a possible failure in my wording just stops others in > answering important questions (what happens a lot lately), simply > because its interupting "the flow" ;o) Pointing out confusion between allocations and assignments, and who does what, is necessary because the questions can't be answered unless the proper terms are used. Gert Doering -- NetMaster -- have you enabled 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From tk at abusix.com Thu Jul 4 17:44:56 2013 From: tk at abusix.com (Tobias Knecht) Date: Thu, 4 Jul 2013 08:44:56 -0700 Subject: [anti-abuse-wg] =?utf-8?q?=5Bdb-wg=5D_abuse-c_+_org?= In-Reply-To: References: <51CBF288.8000801@restena.lu> <51D1A9FA.60009@ripe.net> <51D29D3F.4090608@restena.lu> <51D3121B.20703@abusix.com> <51D33AB2.1010904@restena.lu> <51D44859.8060908@abusix.com> <51D48F39.7040609@restena.lu> Message-ID: Hi there, > As I can obviously only speak for myself,? > I'd love to hear from others if it was clear to them that an abuse-c? > could ONLY be linked to an organisation.? This wasn't clear to me either.? https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06 [?]This means each resource object which is subject to, and in compliance with, RIPE Policy will inherit abuse contact information from its?organisation?object. Each RIPE NCC member should maintain correct contact information representing their organisation, including the new abuse details, in the?organisation?object.[?] [?]The resource is not directly linked to an abuse contact role, but they are connected through the?organisation?object.[?] This is the implementation document and this was base for the decision as requested by community, since the policy text didn't go deep enough into implementation and community didn't want to do a decision based on the policy text without knowing exact implementation details.? Thanks, Tobias From pk at DENIC.DE Thu Jul 4 19:36:09 2013 From: pk at DENIC.DE (Peter Koch) Date: Thu, 4 Jul 2013 19:36:09 +0200 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits In-Reply-To: <20130704153125.GB2706@Space.Net> References: <51D58C1E.6070100@powerweb.de> <20130704145650.GZ2706@Space.Net> <51D591B5.9090503@powerweb.de> <20130704153125.GB2706@Space.Net> Message-ID: <20130704173609.GE17456@x28.adm.denic.de> On Thu, Jul 04, 2013 at 05:31:25PM +0200, Gert Doering wrote: > No, because that situation can not happen. The LIR does not specify > a purpose, so there is no way they could be used for a "different purpose". in all fairness, Andrew's response made the 'purpose' compliance of the assignments subject to the evaluation in his response. Now, I'd appreciate a clarification from the NCC what level of abstraction they consider a 'purpose' in this sense. I'd be surprise to learn this is a website screening or any traffic assessment. I could, however, understand if this included a check of proper application of the assignment rules. To that extent, believe it or not, an assignee stating ''I'm gonna send lotsa mails'' has demonstrated more of a technical need than someone claiming they love and collect small prime numbers in IP addresses. -Peter From ripe-anti-spam-wg at powerweb.de Thu Jul 4 20:22:25 2013 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Thu, 04 Jul 2013 20:22:25 +0200 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits In-Reply-To: <20130704173609.GE17456@x28.adm.denic.de> References: <51D58C1E.6070100@powerweb.de> <20130704145650.GZ2706@Space.Net> <51D591B5.9090503@powerweb.de> <20130704153125.GB2706@Space.Net> <20130704173609.GE17456@x28.adm.denic.de> Message-ID: <51D5BD61.2000205@powerweb.de> Peter Koch wrote: > On Thu, Jul 04, 2013 at 05:31:25PM +0200, Gert Doering wrote: > >> No, because that situation can not happen. Sure it can ! If I remember old times right, we first got our allocation when becoming a RIPE member and had a very small assignment window. We had to send network plans to the NCC for the first assignments we made and because they were acceptable, our assignment windows was raised, so we could assign most IP blocks for our customers ourself from then on up to our new assignment windows, but surely we still have to track that our assignments comply and need to know wich customer uses wich block for what. So: theres is a lot of assignment *purposed* RIPE NCC should know about directly and the others should be known to the LIR. The question is: is the NCC ordering network plans from the LIR during an audit to check the purpose ? Lets say the LIR is saying: network xy was assigned to customer yz and the customers sayd the purpose was "routing equipment". And now the NCC realizes that there is lots of spam and other abuse coming out of these assignments. What happens: has the LIR to cancel the contract with its customer ? Or switch the use back to "routing equipment" ? And if this kind of confusion is true for most of the assignments for the LIR ? Will the LIR take this as a sign for a "bad" LIR and terminate its contract ? Or lower his assignment windows ? I would really like to have an example of a audit process that ended bad for the LIR or its customers ... how did it really worked ... > The LIR does not specify >> a purpose, so there is no way they could be used for a "different purpose". > > in all fairness, Andrew's response made the 'purpose' compliance > of the assignments subject to the evaluation in his response. > Now, I'd appreciate a clarification from the NCC what level of > abstraction they consider a 'purpose' in this sense. Exactly :o) > I'd be surprise > to learn this is a website screening or any traffic assessment. > I could, however, understand if this included a check of proper > application of the assignment rules. To that extent, believe it > or not, an assignee stating ''I'm gonna send lotsa mails'' > has demonstrated more of a technical need than someone claiming > they love and collect small prime numbers in IP addresses. > > -Peter > > Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== From jorgen at hovland.cx Thu Jul 4 21:07:56 2013 From: jorgen at hovland.cx (=?ISO-8859-1?Q?J=F8rgen_Hovland?=) Date: Thu, 04 Jul 2013 21:07:56 +0200 Subject: [anti-abuse-wg] Sending SPAM In-Reply-To: <51D51938.8050100@powerweb.de> References: <51D51938.8050100@powerweb.de> Message-ID: <51D5C80C.8030402@hovland.cx> Den 7/4/13 8:42 AM, skrev Frank Gadegast: > lhcarrara at gmail.com wrote: > >> >> Well, I'm having problems with SPAM from provider OVH. > > OVH is known to us for ignoring abuse reports and also > known here not to invest a lot of work in cleaning their > networks. > > Dont waste your time with them, blacklist their IPs and > your done. > > It's rather extreme stating something like that. As I understand from the original mail, the contact information for the inetnum is incorrect. You simply send an email to the LIR (OVH) complaining about the incorrect contact information. If they ignore your complaint, you send it to the RIR instead. After the LIR or the RIR has corrected the contact information, you can resend your complaint. As always, anyone can ignore your spam complaint if it doesn't violate any national law. Blacklisting the provider of the offending party is just silly. Blacklist just the spam instead. > Kind regards, Frank > >> I have received >> several of them in recent weeks, but not when I am finding solution >> complaints. When I started to complain to the email abuse at ovh.net >> (that does not work, even), and then the e-mail >> suporte at ovh.net , the operator asked me to get >> in touch directly with the email abuse that listed in the register of IP >> RIPE.NET . It is what I have done. But in recent days, >> the customer who owns the OVH email spam-control at hospedagemgenial.com.br >> been sending me various >> SPAM. But this email (spam-control at hospedagemgenial.com.br >> ) does not exist, so my >> complaints are not enough. So, I began to denounce the SPAM directly to >> OVH, but nothing was done. I keep getting these SPAM. I do not know if >> they do not have infrastructure to filter it, or do not want to block >> the account of spamming, but keep getting the messages. >> To my enchegar things, when a carrier sells a framework for sending >> emails advertising (fancy name for SPAM), it is also responsible for >> such transmission. I did not ask her client (the >> spam-control at hospedagemgenial.com.br >> ) send me SPAM. These >> customers simply take our e-mail who knows where and start sending us >> spam. And when we complained, the provider does nothing. >> I can not stand staying receiving such messages, do not want to receive >> and do not want to be made a fool by clicking on "click here to >> unsubscribe" because I know I'll keep getting spam from the same >> company, only one other product. >> Wish you could help me make a formal complaint about the sending of SPAM >> opereradora OVH or, if not the responsibility of you, if you could show >> me how it should be done. >> Thank you for your attention. >> Henrique > > From lists-ripe at c4inet.net Thu Jul 4 21:30:52 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 4 Jul 2013 20:30:52 +0100 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits In-Reply-To: <51D5BD61.2000205@powerweb.de> References: <51D58C1E.6070100@powerweb.de> <20130704145650.GZ2706@Space.Net> <51D591B5.9090503@powerweb.de> <20130704153125.GB2706@Space.Net> <20130704173609.GE17456@x28.adm.denic.de> <51D5BD61.2000205@powerweb.de> Message-ID: <20130704193052.GA25954@cilantro.c4inet.net> On Thu, Jul 04, 2013 at 08:22:25PM +0200, Frank Gadegast wrote: >Lets say the LIR is saying: network xy was assigned >to customer yz and the customers sayd the purpose >was "routing equipment". >And now the NCC realizes that there is lots of >spam and other abuse coming out of these assignments. I don't speak for the NCC but IIRC the NCC checks that *a* technical need for the assignment still exist, *not* that it is the same topology as 10 years ago when the block was first assigned. In real network operations, the network does not stay the same forever, what was assigned to a router 3 years ago may be assigned to a mail server or a DSL line today. >What happens: has the LIR to cancel the contract with >its customer ? If there still is a need for the assignemnt, nothing happens. If not, the assignment must be returned to the LIR. The NCC has no authority over who a LIR does business with. rgds, Sascha Luck From ripe-anti-spam-wg at powerweb.de Thu Jul 4 21:53:31 2013 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Thu, 04 Jul 2013 21:53:31 +0200 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits In-Reply-To: <20130704193052.GA25954@cilantro.c4inet.net> References: <51D58C1E.6070100@powerweb.de> <20130704145650.GZ2706@Space.Net> <51D591B5.9090503@powerweb.de> <20130704153125.GB2706@Space.Net> <20130704173609.GE17456@x28.adm.denic.de> <51D5BD61.2000205@powerweb.de> <20130704193052.GA25954@cilantro.c4inet.net> Message-ID: <51D5D2BB.7090305@powerweb.de> Sascha Luck wrote: >> What happens: has the LIR to cancel the contract with >> its customer ? > > If there still is a need for the assignemnt, nothing happens. If not, > the assignment must be returned to the LIR. > The NCC has no authority over who a LIR does business with. > rgds, > Sascha Luck So, does anybody knows any reason how the NCC could revoke an assignment or even an allocation, if there is a technical need and all contract data and RIPE entries are conform to the current regulations ? There SHOULD be a possibility how the NCC could revoke assignments, if they are used for obvious abuse. Sounds ridiculous to me, if there is none (yet). Sounds like to me, if an owner of a house is renting the appartments in his house to criminals, wich build bombs, plan bank robberies and train terrorists and he has no way to terminate or restrict the contract as long as the criminals pay the rent and empty the letterbox ... (sorry for the harsh example, but I think it somehow fits). (and dont tell me we need the descision of a judge in the Netherlands) Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== -- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== From peter at hk.ipsec.se Thu Jul 4 21:55:18 2013 From: peter at hk.ipsec.se (peter h) Date: Thu, 4 Jul 2013 21:55:18 +0200 Subject: [anti-abuse-wg] Sending SPAM In-Reply-To: <51D5C80C.8030402@hovland.cx> References: <51D51938.8050100@powerweb.de> <51D5C80C.8030402@hovland.cx> Message-ID: <201307042155.18880.peter@hk.ipsec.se> On Thursday 04 July 2013 21.07, J?rgen Hovland wrote: > Den 7/4/13 8:42 AM, skrev Frank Gadegast: > > lhcarrara at gmail.com wrote: > > > >> > >> Well, I'm having problems with SPAM from provider OVH. > > > > OVH is known to us for ignoring abuse reports and also > > known here not to invest a lot of work in cleaning their > > networks. > > > > Dont waste your time with them, blacklist their IPs and > > your done. > > > > > > > It's rather extreme stating something like that. > As I understand from the original mail, the contact information for the > inetnum is incorrect. You simply send an email to the LIR (OVH) > complaining about the incorrect contact information. If they ignore your > complaint, you send it to the RIR instead. > After the LIR or the RIR has corrected the contact information, you can > resend your complaint. > > As always, anyone can ignore your spam complaint if it doesn't violate > any national law. > Blacklisting the provider of the offending party is just silly. > Blacklist just the spam instead. I tend to disagree .. a provider that does not care AT ALL is an infected area that spreads diseases. Until they clean up one has a better life without their worms. If OVH does not feel the pressure they will never act. When their users start complaining that they cannot send mail then they might act. If not their users may move to a professional ISP. This is "the force of the market" , customers choose what gives them "bang for their buck" > > > > > > Kind regards, Frank > > > >> I have received > >> several of them in recent weeks, but not when I am finding solution > >> complaints. When I started to complain to the email abuse at ovh.net > >> (that does not work, even), and then the e-mail > >> suporte at ovh.net , the operator asked me to get > >> in touch directly with the email abuse that listed in the register of IP > >> RIPE.NET . It is what I have done. But in recent days, > >> the customer who owns the OVH email spam-control at hospedagemgenial.com.br > >> been sending me various > >> SPAM. But this email (spam-control at hospedagemgenial.com.br > >> ) does not exist, so my > >> complaints are not enough. So, I began to denounce the SPAM directly to > >> OVH, but nothing was done. I keep getting these SPAM. I do not know if > >> they do not have infrastructure to filter it, or do not want to block > >> the account of spamming, but keep getting the messages. > >> To my enchegar things, when a carrier sells a framework for sending > >> emails advertising (fancy name for SPAM), it is also responsible for > >> such transmission. I did not ask her client (the > >> spam-control at hospedagemgenial.com.br > >> ) send me SPAM. These > >> customers simply take our e-mail who knows where and start sending us > >> spam. And when we complained, the provider does nothing. > >> I can not stand staying receiving such messages, do not want to receive > >> and do not want to be made a fool by clicking on "click here to > >> unsubscribe" because I know I'll keep getting spam from the same > >> company, only one other product. > >> Wish you could help me make a formal complaint about the sending of SPAM > >> opereradora OVH or, if not the responsibility of you, if you could show > >> me how it should be done. > >> Thank you for your attention. > >> Henrique > > > > > > > > > -- Peter H?kanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det ?r billigare att g?ra r?tt. Det ?r dyrt att laga fel. ) From lists-ripe at c4inet.net Thu Jul 4 22:22:08 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 4 Jul 2013 21:22:08 +0100 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits In-Reply-To: <51D5D2BB.7090305@powerweb.de> References: <51D58C1E.6070100@powerweb.de> <20130704145650.GZ2706@Space.Net> <51D591B5.9090503@powerweb.de> <20130704153125.GB2706@Space.Net> <20130704173609.GE17456@x28.adm.denic.de> <51D5BD61.2000205@powerweb.de> <20130704193052.GA25954@cilantro.c4inet.net> <51D5D2BB.7090305@powerweb.de> Message-ID: <20130704202208.GB25954@cilantro.c4inet.net> On Thu, Jul 04, 2013 at 09:53:31PM +0200, Frank Gadegast wrote: >So, does anybody knows any reason how the NCC could >revoke an assignment or even an allocation, if >there is a technical need and all contract data >and RIPE entries are conform to the current >regulations ? TTBOMK, as long as policy requirements are fulfilled there is no mandate to revoke resources. Even if a LIR is closed for being on an embargo list, as happened recently, the resources were transferred to another, unaffected, LIR. >There SHOULD be a possibility how the NCC could >revoke assignments, if they are used for >obvious abuse. You are, of course free to initiate a policy proposal to that effect. I don't think there is much political will in the community to give the NCC a mandate to police content, however. >Sounds like to me, if an owner of a house >is renting the appartments in his house >to criminals, wich build bombs, plan bank >robberies and train terrorists >and he has no way to terminate or restrict >the contract as long as the criminals >pay the rent and empty the letterbox ... >(sorry for the harsh example, but I think >it somehow fits). I propose that the use of "terrorist" in any argument renders this argument invalid immediately. You may call it "Luck's Law" if it hasn't got a name yet... rgds, Sascha Luck From gert at space.net Fri Jul 5 14:31:54 2013 From: gert at space.net (Gert Doering) Date: Fri, 5 Jul 2013 14:31:54 +0200 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits In-Reply-To: <51D5D2BB.7090305@powerweb.de> References: <51D58C1E.6070100@powerweb.de> <20130704145650.GZ2706@Space.Net> <51D591B5.9090503@powerweb.de> <20130704153125.GB2706@Space.Net> <20130704173609.GE17456@x28.adm.denic.de> <51D5BD61.2000205@powerweb.de> <20130704193052.GA25954@cilantro.c4inet.net> <51D5D2BB.7090305@powerweb.de> Message-ID: <20130705123154.GN2706@Space.Net> Hi, On Thu, Jul 04, 2013 at 09:53:31PM +0200, Frank Gadegast wrote: > Sounds like to me, if an owner of a house > is renting the appartments in his house > to criminals, wich build bombs, plan bank > robberies and train terrorists > and he has no way to terminate or restrict > the contract as long as the criminals > pay the rent and empty the letterbox ... You might want to check german law on this. And indeed, as long as the criminal doesn't make too much noise or dirt with this and doesn't annoy the neighbours, it will be *quite* difficult to terminate the contract on short notice. Gert Doering -- NetMaster -- have you enabled 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From ops.lists at gmail.com Fri Jul 5 15:09:58 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 5 Jul 2013 18:39:58 +0530 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits In-Reply-To: <20130705123154.GN2706@Space.Net> References: <51D58C1E.6070100@powerweb.de> <20130704145650.GZ2706@Space.Net> <51D591B5.9090503@powerweb.de> <20130704153125.GB2706@Space.Net> <20130704173609.GE17456@x28.adm.denic.de> <51D5BD61.2000205@powerweb.de> <20130704193052.GA25954@cilantro.c4inet.net> <51D5D2BB.7090305@powerweb.de> <20130705123154.GN2706@Space.Net> Message-ID: I am not a lawyer, and certainly not eine rechtsanwalt, but it is a universal principle of contract law that a contract formed for a criminal actions / with criminal intent (actus reus / mens rea) is invalid, ab initio. You may want to examine how this affects your statement. On Friday, July 5, 2013, Gert Doering wrote: > Hi, > > On Thu, Jul 04, 2013 at 09:53:31PM +0200, Frank Gadegast wrote: > > Sounds like to me, if an owner of a house > > is renting the appartments in his house > > to criminals, wich build bombs, plan bank > > robberies and train terrorists > > and he has no way to terminate or restrict > > the contract as long as the criminals > > pay the rent and empty the letterbox ... > > You might want to check german law on this. And indeed, as long as > the criminal doesn't make too much noise or dirt with this and doesn't > annoy the neighbours, it will be *quite* difficult to terminate the > contract on short notice. > > Gert Doering > -- NetMaster > -- > have you enabled 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 > -- --srs (iPad) -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank at powerweb.de Thu Jul 4 22:42:06 2013 From: frank at powerweb.de (Frank Gadegast) Date: Thu, 04 Jul 2013 22:42:06 +0200 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits In-Reply-To: <20130704202208.GB25954@cilantro.c4inet.net> References: <51D58C1E.6070100@powerweb.de> <20130704145650.GZ2706@Space.Net> <51D591B5.9090503@powerweb.de> <20130704153125.GB2706@Space.Net> <20130704173609.GE17456@x28.adm.denic.de> <51D5BD61.2000205@powerweb.de> <20130704193052.GA25954@cilantro.c4inet.net> <51D5D2BB.7090305@powerweb.de> <20130704202208.GB25954@cilantro.c4inet.net> Message-ID: <51D5DE1E.6050906@powerweb.de> Sascha Luck wrote: > TTBOMK, as long as policy requirements are fulfilled > there is no mandate to revoke resources. Any spammer on this list (think so, simply because of the lack of progress) ? * Im starting now a second carrier in renting all the IPv4 addresses left in our allocation exclusively to abusers and make a lot of money with it. Just make offers now. * Will surely put a working abuse contact email address in RIPEs db, that gets directed to /dev/null and have a correct postal address somewhere on a funny island ... And it looks like if nobody could ever do anything against it. The current regulations are simply slippery as an eel (like we say in Germany), no way to catch anybody responsible. Again, ridicolous ... Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== From ops.lists at gmail.com Mon Jul 8 09:04:47 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 8 Jul 2013 12:34:47 +0530 Subject: [anti-abuse-wg] Clarification Regarding Needs Assessment and Audits In-Reply-To: <51D5DE1E.6050906@powerweb.de> References: <51D58C1E.6070100@powerweb.de> <20130704145650.GZ2706@Space.Net> <51D591B5.9090503@powerweb.de> <20130704153125.GB2706@Space.Net> <20130704173609.GE17456@x28.adm.denic.de> <51D5BD61.2000205@powerweb.de> <20130704193052.GA25954@cilantro.c4inet.net> <51D5D2BB.7090305@powerweb.de> <20130704202208.GB25954@cilantro.c4inet.net> <51D5DE1E.6050906@powerweb.de> Message-ID: The lack of progress is simply because you have very few people who are in a security rather than IP admin or network ops role. Security as in for a seriously large provider. The other lack of progress - well, changing entrenched policies, or enforcing them beyond a point where the enforcer is reluctant to investigate (or is it "play police" according to the local meme) is as tough as it sounds. On Friday, July 5, 2013, Frank Gadegast wrote: > Sascha Luck wrote: > > TTBOMK, as long as policy requirements are fulfilled >> there is no mandate to revoke resources. >> > > Any spammer on this list (think so, simply because > of the lack of progress) ? > > * Im starting now a second carrier in renting all > the IPv4 addresses left in our allocation exclusively > to abusers and make a lot of money with it. > Just make offers now. * > > Will surely put a working abuse contact email address > in RIPEs db, that gets directed to /dev/null > and have a correct postal address somewhere on > a funny island ... > > And it looks like if nobody could ever do anything > against it. > > The current regulations are simply slippery as > an eel (like we say in Germany), no way > to catch anybody responsible. Again, ridicolous ... > > > Kind regards, Frank > -- > PHADE Software - PowerWeb http://www.powerweb.de > Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de > Schinkelstrasse 17 fon: +49 33200 52920 > 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 > ==============================**==============================**========== > > -- --srs (iPad) -------------- next part -------------- An HTML attachment was scrubbed... URL: From PublicIPAddressing at charter.com Tue Jul 9 17:39:33 2013 From: PublicIPAddressing at charter.com (Public IP Addressing) Date: Tue, 9 Jul 2013 10:39:33 -0500 Subject: [anti-abuse-wg] Who owns 24.205.98.101? In-Reply-To: <16620961.1372781433989.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> References: <16620961.1372781433989.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Message-ID: <1DB5A12D98EB024FA4A9D0355029655A019BFA2AA3@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM> Charter cares deeply about the privacy of our subscribers? information and will protect the privacy of our subscribers even while working with law enforcement to prevent criminal activity. If you are unsure about our privacy practices, please visit: Charter?s Privacy Policy @ http://charter.com/footer/footerPage.jsp?tag=privacy If this is an Abuse related issue please forward all logs to abuse at charter.net and our Security & Abuse Team will investigate. If this is a law enforcement issue please visit http://www.charter.com/lea/ for additional information. Thank You, Charter Communications IP Addressing -----Original Message----- From: Reza Farzan [mailto:rezaf at mindspring.com] Sent: Tuesday, July 02, 2013 11:11 AM To: Olaf van der Spek; anti-abuse-wg at ripe.net Cc: DL NOC IP; Public IP Addressing Subject: Re: [anti-abuse-wg] Who owns 24.205.98.101? Hello Olaf, Yes, not a single response from Charter, and I am not surprised. Charter Communications [charter.net & charter.com] is one of those mega providers that does not respond to such questions. Their Contact Page, http://www.myaccount.charter.com/Customers/ContactUs.aspx, deals mainly with their customers and their related inquiries. But calling Charter's National Network Operations Center (+1-314-288-3111) could be the last option, if they actually answer that line. With countless servers and IPs, Charter may not be as responsive as we expect them to be. Thank you, Reza Farzan ++++++++++ -----Original Message----- >From: Olaf van der Spek >Sent: Jul 2, 2013 10:29 AM >To: Reza Farzan >Subject: Re: [anti-abuse-wg] Who owns 24.205.98.101? > >On Tue, Jun 25, 2013 at 4:07 PM, Reza Farzan wrote: >> Hello Peter, >> >> The Whois information clearly shows this IP to be part of Charter Communications network: >> >> NetRange: 24.205.76.0 - 24.205.99.255 >> CIDR: 24.205.96.0/22, 24.205.80.0/20, 24.205.76.0/22 >> OriginAS: >> NetName: CHAR-PAS-205-76-99 >> NetHandle: NET-24-205-76-0-1 >> Parent: NET-24-205-0-0-1 >> NetType: Reallocated >> RegDate: 2001-09-30 >> Updated: 2003-08-27 >> Ref: http://whois.arin.net/rest/net/NET-24-205-76-0-1 >> >> OrgName: Charter Communications >> OrgId: CC04 >> Address: 12405 Powerscourt Dr. >> City: St. Louis >> StateProv: MO >> PostalCode: 63131 >> Country: US >> RegDate: >> Updated: 2012-07-03 >> Ref: http://whois.arin.net/rest/org/CC04 >> >> OrgTechHandle: IPADD1-ARIN >> OrgTechName: IPAddressing >> OrgTechPhone: +1-314-288-3889 >> OrgTechEmail: ipaddressing at chartercom.com >> OrgTechRef: http://whois.arin.net/rest/poc/IPADD1-ARIN >> >> OrgAbuseHandle: ABUSE19-ARIN >> OrgAbuseName: Abuse >> OrgAbusePhone: +1-314-288-3111 >> OrgAbuseEmail: abuse at charter.net >> OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE19-ARIN >> >> OrgNOCHandle: NNOC16-ARIN >> OrgNOCName: National Network Operations Center >> OrgNOCPhone: +1-314-288-3111 >> OrgNOCEmail: dlnocip at chartercom.com >> OrgNOCRef: http://whois.arin.net/rest/poc/NNOC16-ARIN >> >> ++++ >> >> So, I do not understand why they are telling you otherwise. >> >> I have copied the responsible parties at Charter Communication so that they could investigate this matter further. ++++ Not a single response from Charter it seems. What's next? From vovan at fakmoymozg.ru Thu Jul 11 11:08:35 2013 From: vovan at fakmoymozg.ru (vovan at fakmoymozg.ru) Date: Thu, 11 Jul 2013 16:08:35 +0700 Subject: [anti-abuse-wg] =?utf-8?q?Who_owns_24=2E205=2E98=2E101=3F?= In-Reply-To: <1DB5A12D98EB024FA4A9D0355029655A019BFA2AA3@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM> References: <16620961.1372781433989.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> <1DB5A12D98EB024FA4A9D0355029655A019BFA2AA3@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM> Message-ID: >> If this is a law enforcement issue please visit >> http://www.charter.com/lea/ for additional information. > An unexpected error occurred > Due to a technical problem we cannot service your request. Please try > again later. From ripencc-management at ripe.net Mon Jul 15 17:08:39 2013 From: ripencc-management at ripe.net (Paul Rendek) Date: Mon, 15 Jul 2013 17:08:39 +0200 Subject: [anti-abuse-wg] RIPE NCC Report: Law Enforcement Agency Requests 2012 Message-ID: <979921EF-5ACC-4A4F-A018-60DEE8E23493@ripe.net> [Apologies for duplicates] Dear colleagues, As mentioned in the Anti-Abuse Working Group session at RIPE 66, the RIPE NCC has published a transparency report that details the nature of the requests we received from Law Enforcement Agencies (LEAs) in 2012. You can find the report here: http://www.ripe.net/ripe/docs/ripe-593 Kind regards, Paul Rendek Director of External Relations RIPE NCC From shane at time-travellers.org Tue Jul 16 11:17:46 2013 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 16 Jul 2013 11:17:46 +0200 Subject: [anti-abuse-wg] RIPE NCC Report: Law Enforcement Agency Requests 2012 In-Reply-To: <979921EF-5ACC-4A4F-A018-60DEE8E23493@ripe.net> References: <979921EF-5ACC-4A4F-A018-60DEE8E23493@ripe.net> Message-ID: <20130716111746.0bc81b61@earth.home.time-travellers.org> Paul, On Mon, 15 Jul 2013 17:08:39 +0200 Paul Rendek wrote: > As mentioned in the Anti-Abuse Working Group session at RIPE 66, the > RIPE NCC has published a transparency report that details the nature > of the requests we received from Law Enforcement Agencies (LEAs) in > 2012. > > You can find the report here: > http://www.ripe.net/ripe/docs/ripe-593 Thank you very much for this report! It looks like the RIPE NCC has handled things exactly right. I am also happy that the information available to the public is the very information that the police need, so there is no need for private information channels. :) Thanks again, -- Shane