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

Re: [anti-abuse-wg] Abuse-C attributes - required e-mail address contact method.
by Ronald F. Guilmette 18 Mar '15

18 Mar '15

My two cents... The person/company who proposed this proposal used the word "complainant" to refer to someone (anyone) attempting to report a case of network abuse to its source network administrators. Personally, speaking only for myself, I object to being called a "complainant" or a "complainer", e.g. when I attempt to do the decent thing and take up _my_ valuable time to notify responsible (?) network administrators about something I feel that they themselves may want to know about, and indeed should want to know about. Of course, the Powers That Be at many networks ... the bean counters and the higher level managers... often view _any_ communication with any party other than a paying customer as a waste of time and money, and thus, the personel underneath these folks inevitably come to develop an "us versus them" attitude which leads inevitably to viewing reports generated by outsiders, aka non-paying customers, as "complaints" and the senders as "complainers" whose only (or primary) goal is to cost the receiving company time and money, rather than the opposite, i.e. attempting to _help_ the receiving company. I would argue that it is this bean counter attitute that has itself given rise to most of the abuse on the Internet, i.e. in the time since the broad commercialization of the net in the mid 1990's. If you view receiving, understanding, and acting upon notifications of bad behavior occuring on your network as nothing other than a non-profit-generating cost sink, then you are entirely less likely to ever actually *do* anything about such reports. And when you don't, the word goes out among the bad guy communities on the Internet, and your network ends up being the source of ever more network abuse. This is just the (Darwinian) way things are. Opportunistic leeches abound. If given safe homes, they and their activities proliferate. I generally expend a good deal of time and effort writing up any abuse report I send. (Note that I say "report" not "complaint".) There are plenty of ways that various networks have dreamed up to avoid reading these "complaints", i.e. because they don't immediately or obviously generate any instantaneous revenue or profits for the receipient networks. The simplest method to avoid spending any non-profit-generating company man hours on reading abuse reports is just to alias abuse@network to /dev/null. If Virgin feels that reading incoming e-mail reports is not worth their time, then I respectfully suggest that they simply enter devnull(a)example.com into the abuse contact e-mail address fields for all of their relevant RIPE database records. This will be maximally efficient for all concerned. (There really is no more efficient way for Virgin to process all of their incoming "complaints". And since they _are_ clearly concerned about the efficiency of this process, that would seem to be ttheir best solution.) Regards, rfg

3 3

Re: [anti-abuse-wg] Abuse-C attributes - required e-mail address contact method.
by Thorsten 14 Mar '15

14 Mar '15

> Am 14.03.2015 um 07:35 schrieb andre(a)ox.co.za: > > On Fri, 13 Mar 2015 17:03:25 +0100 > Gert Doering <gert(a)space.net> wrote: >> On Fri, Mar 13, 2015 at 03:18:17PM +0000, Gist, Jonathan wrote: >>> The RIPE policy around the abuse-c attribute requires the presence >>> of an e-mail address, which is asked to be used by subscribers >>> wishing to report abuse incidents. This contact method is resource >>> intensive and Virgin Media would like to propose a change to the >>> policy to remove the requirement for an e-mail address contact >>> field. >>> Virgin Media would like to specify virginmedia.com/netreport (a >>> web-form that feeds an abuse case management system) I would support an *additional field* for „abuse-webform“ in the abuse-c attributes, to ensure that *manual reports* contain everything what is needed for an ISP to act on, beside the "abuse-mailbox“ for automated (e.g. X-ARF complaints). But not in the fashion that it is getting the „single point of contact“. >> I would not support such a change, at least not without a *well >> defined* format for such web forms. For companies like us, reporting out thousands of abuse-reports (phishing sites, malware complaints, etc.) per day, webforms are making it impossible to report abuse. >> On the reporting side of abuse, it is just way too much work to >> figure out how particular ISPs expect to receive abuse reports, >> offloading half the work of abuse handling to the reporter. >> (I report quite a lot of abuse, but I refuse to do anything but >> e-mail, because it is just too much work for me - it's your >> customers, they are giving *you* money, their abuse should not cost >> *me* extra time). Exactly! Rgds, Thorsten

1 0

Re: [anti-abuse-wg] anti-abuse-wg Digest, Vol 41, Issue 2
by Karl-Josef Ziegler 13 Mar '15

13 Mar '15

> Virgin Media would like to specify virginmedia.com/netreport (a > web-form that feeds an abuse case management system) in the abuse > attribute to ensure that we are able to properly manage and > prioritise abuse complaints. If we have the web-form listed as the > abuse contact we are able to maximise appropriate abuse handling > measures to prevent misuse of our network and thereby ensure an > optimum experience for all complainants. I also don't support this proposal because filling (maybe also a different form for each ISP) webforms correctly is a tedious work and only transfers parts of the workload from abuse desk to the reporter. But the reporter is not responsible for the abuse; responsibility lies with the ISP so the workload must be done there. Best regards, - Karl-Josef Ziegler

1 0

Draft AA WG Minutes - RIPE 69
by Brian Nisbet 04 Mar '15

04 Mar '15

Colleagues, Here are the draft minutes from the AA-WG meeting at RIPE69. Could you please take a look and come back to me with any corrections on your part? Thanks, Brian --------- Anti-Abuse Working Group Draft Minutes - RIPE 69 Date: 5 November 2015, 14:00-15:30 Working Group Co-Chairs: Brian Nisbet, Tobias Knecht Scribe: Marco Hogewoning Status: Draft Brian Nisbet, WG co-chair, welcomed the attendees and apologised on behalf of Tobias Knecht who due to illness could not attend the session. A. Administrative Matters Brian apologised for the minutes of RIPE 68 being sent out late and asked the audience if there where any comments or additions. Alexander Isavin, NetLine, mentioned that the section on law enforcement agencies is missing from the minutes. Brian says he remembers the discussion and will look into the matter. He asked the working group to approve the session's agenda, which they did without further comments. B. Update - Brian Nisbet, AA Working Group Co-Chair Brian mentioned the charter was discussed in Warsaw and some follow up discussion took place in June. The new charter has been published on the website and Brian closed this action point. Brian introduced the procedure to select working group chairs and gave the working group some background on why this is needed. A draft text was sent to the mailing list and a version with some minor changes in wording was published on Tuesday evening. Brian highlighted the main elements of the proposal that the chairs will have a term, there will be no limit on the number of terms and each term will last for three years. There will be two or a maximum of three chairs for the working group and the decision on who will become chair preferably is made by consensus or alternatively by a secret ballot. Brian asked if there were any further comments and deferred the discussion back to the mailing list to come to a conclusion about this topic Sander Steffann raised his thumb. Brian pointed to a discussion the mailing list about AS Numbers and said that due to the recent number of emails he was not able to catch up.He suggested to leave the discussion on the mailing list as more people are likely to be behind on this topic. Brain mentioned that the RIPE NCC was already looking into some of the questions raised in the list and was expected to reply. He clarified the discussion has to do with the credentials supplied when an AS Number is requested and any allocations that have been revoked. C. Policies Brian mentioned that due to Tobias' illness they haven’t looked into the issue and mentioned that a conference call with the RIPE NCC has been planned in December to talk about this. D2: RIPE NCC anti-abuse outreach activities Mirjam Keuhne and Ivo Dijkhuis from the RIPE NCC presented about their outreach activity. A copy of the presentation is available at https://ripe69.ripe.net/presentations/116-SecurityUpdate4RIPE69.pdf Brian reminded Mirjam about an open action point for the RIPE NCC from Warsaw to send some more information to the list, which hadn’t happened yet. D3. RIPE NCC Governemnt/LEA Interactions Update Marco Hogewoning, RIPE NCC, gave a short update on the interactions with law enforcement and governments. An archived copy of Marco’s presentation is available at https://ripe69.ripe.net/archives/video/10140/ Coming back to Alexander Isavin’s earlier question about the minutes, Marco mentioned there is an open action point to provide more information about the LEA meetings. As there haven’t been any LEA meetings yet, this information was not published. Heather Schiller, ARIN, asked if the RIPE NCC published a report about the number of LEA enquiries they receive. Marco mentioned the RIPE NCC in 2012 and 2013 published a transparency report which is available on the website. Ruediger Volk, Deutsche Telekom, pointed out that the report does not list the level of access given to law enforcement agencies. Marco explains the information contained in the report and said that it not only provides the number of enquiries but also gives some information on where the are coming from and provides an overview of the nature and reason of declined requests. E2. Tor censorship countermeasures and how you can help Jurre van Bergen, Greenhost, presented about countermeasures to Tor censorship. A copy of the presentation is available at https://ripe69.ripe.net/presentations/112-tor-ripe69.pdf Erik Bais, A2B Networks, asked if he understood correctly that Jurre had set up a foundation for this and what kind of work was involved in running an exit node. Jurre clarified that the foundation was set up to maintain a dialogue with the law enforcement community and to actively assist them with warrants and subpoenas. He said they are happy to provide operators with training and help them to set up and suggested to take the discussion private. Brian Nisbet mentioned that research networks have two issues with running tor exit nodes. One being the acceptable use policy prohibiting ^a third party from using these networks for this purpose. The other being that the misconceptions about the Tor project might lead to questions from the governments who fund the research network. Jurre pointed out that majority of funding for the Tor project comes from governments. He explained they are using an IP block from a Dutch research institute, but as it was re-purposed they are not really using the research network. Sacha van Geffen, Greenhost, asked if the foundation was busy creating and publishing any best current practices. Jurre answered this is done and gave an example on controlling which ports can be used on a Tor exit node to limit certain services. Brian suggested to Jurre to share some of this information with the mailing list, especially the ones on abuse policy as they relate to the working group. E1. Impact of rom-0 vulnerability in SOHO routers Tomas Hlavacek, NIC.CZ, presented on the ROM vulnerability in routers, an archived copy of his presentation is available at https://ripe69.ripe.net/presentations/61-rom0-vuln.pdf Erik Bais, A2B Internet, asked if the holders of the IP addresses found in the research were notified about the issue. Tomas explained this was not done because people were not interested and the team chose to use mass media to create awareness. Erik suggested to have a chat about this as he had experience with cleaning up botnets and mailing owners might help. Elvis Valea, V4Escrow, asked if there was a list with vulnerable modems available. Tomas answered it is usually the cheaper brands but they would not disclose names as the manufacturers don’t like that. Elvis asked Tomas if they scanned the whole Internet. Tomas confirmed. Heather Schiller, Google, mentioned there are other groups looking into CPE vulnerabilities and it might help to share the data with them. Bruce van Nice, Nominum, asked if any work was done in profiling the resolvers to see which sites were abused. Tomas answered they found one doing Google and Facebook phishing. Marco Hogewoning, RIPE NCC, asked how many abuse reports came in after scanning the entire Internet. Tomas said he received three complaints. E3. DDoS as a service Jair Santanna, Universiteit Twente, presented on Booters: the DDoS as a Service phenomenon. An archived copy of his presentation can be found at https://ripe69.ripe.net/presentations/115-20141105_RIPE69_jjsantanna.pdf A member of the audience mentioned they did some investigation to Booters themselves and find out these often use commercial anti-DDoS protection services as Booters sites tend to attack themselves. He suggested to work with these companies to take the front-end offline. Jair said it is hard to find the evidence, but when they do these sites get taken offline by their providers. X. AOB Brian asked for any other business. Erik Bais mentioned he had noticed that after an IP transfer abuse reports get sent to the old IP address holder and that is a clear indication that people are not using the RIR whois databases and fail to update their own information in time. He said it also takes quite an effort to de-list transferred resources with blacklist operators. Brian asked for suggestions on how the working group can help to improve this. Erik responded that more information about transfers to the abuse community could help and offers to explain how a transfer is actually done. Another suggestion is to make it easier to prove a transfer is legitimate. Ruediger Volk suggested looking into the data flow from the RIPE NCC who administers the transfers to the parties who collect and distribute anti-abuse information. Elvis Valea mentions that they observed BGP hijacks taking place in the brief period a transfer takes place and the RIPE Database objects get deleted. Brian responded that they haven’t discussed BGP hijacks but this is worth looking into as it might require a policy change or change the way transfers are done. Brian Nisbet thanked the attendees for their participation and closed the session.

1 0

How do I report Yahoo e-mail addresses that are engaged in fruad and scams?
by Reza Farzan 16 Feb '15

16 Feb '15

Hello, I would like to know how I can report Yahoo e-mail addresses that are engaged in fruad and scams. The other day, I received a spam with the following information: Mr. Supatha Narkornlee Director of Operations atm Department AsianGroup Thailand . E;mail <automatedtellermachineoffice(a)yahoo.co.th> phone; +669 8328 6013 ++++ But when I reported it to Yahoo Abuse and Spamcop, I received the following message from Yahoo Customer Care: You can use this link to get to the contact us page: https://io.help.yahoo.com/contact/index?page=contact&locale=en_US&y=PROD_MA… This link does NOT offer help, and it require me to sign in in to Yahoo. I do NOT have or use Yahoo e-mail system, but I receive spam messages with Yahoo e-mail addresses in them that are part of the scam. How do I report Yahoo e-mail addresses that are engaged in fruad and scams? I hope to hear from you. Thank you, Reza Farzan

2 1

RIPE 70 Call For Presentations
by Brian Nisbet 15 Jan '15

15 Jan '15

Colleagues, The Call for Presenations for RIPE70 in Amsterdam in May of 2015 has now opened. Please see below for details. Brian Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 70 will take place from 11-15 May 2015 in Amsterdam, The Netherlands. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 70. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at https://ripe70.ripe.net/submit-topic/presentation-formats/ Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for "lightning talks", which are selected immediately before or during the conference. The following general requirements apply: - Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 1 March 2015, using the meeting submission system at https://ripe70.ripe.net/submit-topic/submission-form/. Proposals submitted after this date will be considered on a space-available basis. Important Dates regarding RIEP 70 can be found at: https://ripe70.ripe.net/programme/important-dates/ - Lightning talks should also be submitted using the meeting submission system (https://ripe70.ripe.net/submit-topic/submission-form/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice – in some cases on the same day but often one day prior to the relevant session. - Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format at https://ripe70.ripe.net/submit-topic/presentation-formats/. - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, it is expected that most, if not all, presenters/panellists will be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net.

1 0

Re: [anti-abuse-wg] RIPE WHOIS blocked
by Edward Shryane 18 Nov '14

18 Nov '14

Hi Ronald, After looking into legal requirements for protection of personal data in RIPE NCC's service region, our community decided that there should be a limit on the number of queries with personal data served to each IP Address. Person and role objects are considered to contain personal data (email address, phone number(s), postal address), and queries for these objects are subject to a daily limit. Once this daily limit for querying personal data is reached, the IP address is temporarily blocked for the rest of that day. If an IP address repeatedly reaches its daily limit, then it is permanently blocked. By default when querying whois, related objects are also returned (including person and role objects). The '-r' flag can be used to not return related objects, or the '--no-personal' flag to not return person or role objects. For bulk access to the RIPE Database, split files (per object type) are published on the RIPE FTP site: ftp://ftp.ripe.net/ripe/dbase/split/ Regards, Ed Shryane RIPE NCC > > > Apparently, somebody @ RIPE NCC thinks that I have been too curious of late. > > How long should it take for this error to go away? > > ============================================================================= > % This is the RIPE Database query service. > % The objects are in RPSL format. > % > % The RIPE Database is subject to Terms and Conditions. > % See http://www.ripe.net/db/support/db-terms-conditions.pdf > > %ERROR:201: access denied for 69.62.255.118 > % > % Queries from your IP address have passed the daily limit of controlled objects. > % Access from your host has been temporarily denied. > % For more information, see > % http://www.ripe.net/data-tools/db/faq/faq-db/why-did-you-receive-the-error-… > > % This query was served by the RIPE Database Query Service version 1.76 (DB-2) > ============================================================================= > > > I have already written to ripe-dbm(a)ripe.net asking about this and have > received no reply. > > And anyway, can anyone here explain to me what the point is of limiting > WHOIS queries based on the source IP address? > > As far as I can see, this only has the effect of slowing down or blocking > the work of legitimate researchers, such as myself. Anybody who knows > anything about the Internet should know that an IP-address based throttling > system would be almost entirely ineffective against anyone who was seriously > determined to perform bulk harvesting of the RIPE data base via port 43 > (or via port 80 for that matter). > > It seems that I am being slowed down, blocked, and penalized for the sin > of having a static IP address, even while any other fool on the planet > who has a dynamically-assigned broadband IP, or even a dial-up line, > and who knows how to disconnect an reconnect can easily slurp all of > the RIPE data they want, with no real limits. > > In what universe is this non-stupid? > > More to the point, who is it, specifically, within RIPE NCC, that has > the authority to fix this? > > > Regards, > rfg > > > P.S. More stupidity: Based on the text at the URL provided in the > error mesage (see above) the goal of the rate limiting seems to be to > prevent harvesters from collecting too much "contact information". > OK. Fine. But the text on that web page also says that using the > -r option with the WHOIS queries will prevent such contact information > from being returned, thus eliminating the issue... or so one would > think. > > But why then is it the case that once my IP address has hit its head > against this daily limit, I am not even allowed anymore to even make > any more ``safe'' queries with the -r option? I am now locked out > completely. Why? > > Sigh. I guess that I need to go and drag my old 96Kb modem down out > of the closet, dust it off, and get myself a free dial-up AOL account > so that I can work around all of this stupidity. >

3 3

Re: [anti-abuse-wg] [routing-wg] AS43890
by Edward Shryane 18 Nov '14

18 Nov '14

Hello, Correct, here is a nice RIPE Labs article explaining those exceptions: https://labs.ripe.net/Members/denis/reclaim-functionality-for-resource-hold… Also, in case of transfer of holder-ship, as long as a user has access to maintainer password, or can recover it using the standard password recovery -meaning they are the rightful holder of the resource- they should be able to follow above mentioned procedure. Regards, Ed Shryane RIPE NCC > > Gert Doering wrote: > >> Hi, > [...] >>> Can any arbitrary RIPE member remove route objects that were created >>> by any other RIPE member? >> >> >> Generally speaking, no. > > Generally speaking, in order to delete an objecct, you need the same (set of) > credentials you would need to create or modify the object. > > As you correctly point out, there are a couple of exceptions to prevent dead- > lock situations when one party fails to cooperate. Removing a route object is > one of those, iirc; deleting a revDNS delegation entry is another. > >> Gert Doering >> -- NetMaster > > Wilfried > >

1 0

RIPE WHOIS blocked
by Ronald F. Guilmette 18 Nov '14

18 Nov '14

Apparently, somebody @ RIPE NCC thinks that I have been too curious of late. How long should it take for this error to go away? ============================================================================= % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf %ERROR:201: access denied for 69.62.255.118 % % Queries from your IP address have passed the daily limit of controlled objects. % Access from your host has been temporarily denied. % For more information, see % http://www.ripe.net/data-tools/db/faq/faq-db/why-did-you-receive-the-error-… % This query was served by the RIPE Database Query Service version 1.76 (DB-2) ============================================================================= I have already written to ripe-dbm(a)ripe.net asking about this and have received no reply. And anyway, can anyone here explain to me what the point is of limiting WHOIS queries based on the source IP address? As far as I can see, this only has the effect of slowing down or blocking the work of legitimate researchers, such as myself. Anybody who knows anything about the Internet should know that an IP-address based throttling system would be almost entirely ineffective against anyone who was seriously determined to perform bulk harvesting of the RIPE data base via port 43 (or via port 80 for that matter). It seems that I am being slowed down, blocked, and penalized for the sin of having a static IP address, even while any other fool on the planet who has a dynamically-assigned broadband IP, or even a dial-up line, and who knows how to disconnect an reconnect can easily slurp all of the RIPE data they want, with no real limits. In what universe is this non-stupid? More to the point, who is it, specifically, within RIPE NCC, that has the authority to fix this? Regards, rfg P.S. More stupidity: Based on the text at the URL provided in the error mesage (see above) the goal of the rate limiting seems to be to prevent harvesters from collecting too much "contact information". OK. Fine. But the text on that web page also says that using the -r option with the WHOIS queries will prevent such contact information from being returned, thus eliminating the issue... or so one would think. But why then is it the case that once my IP address has hit its head against this daily limit, I am not even allowed anymore to even make any more ``safe'' queries with the -r option? I am now locked out completely. Why? Sigh. I guess that I need to go and drag my old 96Kb modem down out of the closet, dust it off, and get myself a free dial-up AOL account so that I can work around all of this stupidity.

5 5

AS43890
by Ronald F. Guilmette 18 Nov '14

18 Nov '14

Based upon the information I am currently looking at (see below) I now believe that it was perhaps a mistake for myself, and possibly others, to have become focused on the issue of insuring the correctness and/or validity of route objects within the RIPE data base only in those cases where the IP blocks in question are under the dominion of other (non-RIPE) RiRs. It now seems certain to me that the absence of anything even remotely approximating proper validation of RIPE route objects is not, in fact, a problem which is limited to just inter-RiR situations. Apparently, RIPE member LIRs can just as easily hijack the IP blocks of other RIPE members as they can in the case of IP blocks belonging to parties in other regions. Also, RIPE-resident hijackers can just as easily place validating route objects for these hijacked RIPE-issued IP blocks into the RIPE DB as they can for any other hijacked blocks taken from any other region(s). Readily available public data indicates that approximately three weeks ago, on or about October 25th, AS197207, an Iranian ISP, began announcing the following routes to the following chunks of its own properly registered IP space: 31.2.128.0/17 46.51.0.0/17 95.64.0.0/17 164.138.128.0/18 188.229.0.0/17 Prior to AS197207's decision to begin announcing the above routes (which they did, starting on Oct. 25th), it appears that the proprietors of AS43890, a Romanian ISP and RIPE LIR in good standing, apparently elected to announce their own set of routes to some or all of the above Iranian IP blocks, using lots and lots of little deaggregated /24 announcements to do so. Evidence in my possession indicates that some of the /24 blocks in question were in fact used by so-called ``snowshoe spammers'' during the time when AS43890 (aka "Netserv Consult SRL") was routing these blocks. This fact leads me to believe that the proprietor(s) of AS43890 most probably did not in fact have anything like real authorization from AS197207 to announce routes to any of the Iranian AS197207's legitimately registered IP space. Further and additionally, as in the recent case involving (Bulgarian) AS201640, it appears that (Romanian) AS43890 also and likewise created multiple route objects within the RIPE data base as a way of legitimizing what appears to me to have been several substantial IP space hijackings. Lastly, many, most, or all of the fradulent route objects created by AS43890 are still present within the RIPE data base, as of today. I am including a list of all 61 of these below. As was the case with the fradulent route objects created within the RIPE DB by AS201640, these 61 apparently fradulent route objects which were created by the proprietor(s) of AS43890 have likewise also been imported into the MERIT RADb, from the RIPE DB, thus spreading the bogus ``authorization'' to route these blocks even further, in a manner not unlike a viral contaminant. Regards, rfg ======================================================================= route: 188.229.1.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.2.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.3.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.9.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.11.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.16.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.17.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.18.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.19.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.20.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.21.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.22.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.23.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.33.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.35.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.36.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.38.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.39.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.49.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.50.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.51.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.52.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.53.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.54.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.55.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.66.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.89.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.90.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.91.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.92.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.93.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.94.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.95.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.96.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.97.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.98.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.99.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.100.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.101.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.102.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.103.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.104.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.105.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.106.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.107.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.108.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.109.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.110.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.111.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.113.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.114.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.117.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.118.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.119.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.120.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.121.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.122.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.123.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.124.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.125.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.126.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered

8 10