November 2014 - anti-abuse-wg

Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud
by Suresh Ramasubramanian 20 Jun '16

20 Jun '16

I knew the time was, well, ripe for something like this to pop up directly after rfg started asking those questions yesterday. ---------- Forwarded message --------- From: Ronald F. Guilmette <rfg(a)tristatelogic.com> Date: Thu, 6 Nov 2014 at 03:31 Subject: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud To: <nanog(a)nanog.org> I already posted about this rogue AS days ago, but nothing has really changed much, since then, with respect to its hijacking of IP space. Well, at least Brian Krebs was kind anough to write about it: http://krebsonsecurity.com/2014/11/still-spamming-after-all-these-years/ (Please note that that is a convicted felon spamming from the hijacked IP space. He's not allowed to own firearms, but he _can_ apparently own a keyboard.) As of today, AS201640 is still hijacking a total of eleven routes to IP space scattered all over the world... none of which appears to belong to anybody in or near Bulgaria. In fact, it would appear that the organization that is the registrant of AS201640 currently has exactly -zero- IP addresses to call its own. Nobody in a postion to _do_ anything about this gives a darn? As of today: 36.0.56.0/21 41.92.206.0/23 41.198.80.0/20 41.198.224.0/20 61.242.128.0/19 119.227.224.0/19 123.29.96.0/19 177.22.117.0/24 177.46.48.0/22 187.189.158.0/23 202.39.112.0/20

6 8

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 11

New on RIPE Labs: Who's Watching
by Mirjam Kuehne 13 Nov '14

13 Nov '14

Dear colleagues, For those of you who missed Geoff Huston's "Who's Watching" lightning talk during RIPE 69, the write-up is now on RIPE Labs: https://labs.ripe.net/Members/gih/whos-watching Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: ECDSA and DNSSEC by Geoff Huston
by Mirjam Kuehne 11 Nov '14

11 Nov '14

Dear colleagues, Please find another security related article by Geoff Huston on RIPE Labs: Elliptic Curve Digital Signature Algorithm (ECDSA) and DNSSEC https://labs.ripe.net/Members/gih/ecdsa-and-dnssec Kind regards, Mirjam Kuehne RIPE NCC

1 0

Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002
by Gert Doering 09 Nov '14

09 Nov '14

Hi, On Thu, Nov 06, 2014 at 02:55:52PM +0000, anfernandez(a)lavanguardia.es wrote: > When RIPE is actually a judge that decided to protecting internet piracy. You can be sure that RIPE will open an expedient to any LIR that do not pay its fee, but you can keep waiting to see RIPE opening an expedient to investigate bad use of internet by one of their associated LIRs. It should be made totally clear that spamming, pirating movies, and so on is a legitimate usage of IP addresses IF THE JURISDICTION OF THE LIR IN QUESTION PERMITS IT. We might not *like* it, but if it's legal in, say, Romania to send out large amounts of e-mail, attacking the RIPE NCC for providing IP addresses to a LIR in .ro is not the way to fix it. Now, we all might agree that SPAM is evil, and pirating moviez is also evil. What about encouraging political debate? China might have a stance here. What about pictures of men kissing men? Russia might not like that. Things that are totally inacceptable for some parties are things that other parties want protected by freedom of speech, or freedom of doing business. So, the NCC can, will and *should* not act on "things people do not like" - it will (and does) act if being lied to, or if a judge decides that a LIR's business is illegal. In this particular case, I wonder why nobody is yelling at the upstream who is happily forward packets for that AS... due dilligence at accepting customer prefixes would have easily caught the announcements. (Yes, I understand that I'm now officially part of the problem, as I'm obviously not willing to do everything technically possible to stop particular sorts of badness) 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 (0)89/32356-444 USt-IdNr.: DE813185279

7 25

Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002
by Ronald F. Guilmette 07 Nov '14

07 Nov '14

<anfernandez(a)lavanguardia.es> wrote: >Don't waste your time. RIPE is not going to do anything about piracy... I already took my turn, years ago now, howling my disappointment that neither RIPE, nor RIPE NCC, nor any other RiR is willing to play the role of the Internet Police. I'm over that adolecent phase now, and have come to accept what they are, and the fact that no howling on my part is in the least bit likely to change what they are. The RiRs are fundamentally data base companies. I don't intend by saying that to slight them, or anybody associated with them in any way. I am quite completely sure that they also do quite a lot of other very fine work also... making all sorts of logistical arrange- ments for regular meetings, and all that goes with that, and RIPE Labs produces some fine tools and excelent technical reports. In short, they do a _lot_ of fine work. But at base, their first order task... RIPE NCC anyway... is the orderly allocation of resources and the maintenance of the data base. Anybody who knows anything about the history of the United States, as I do, can grasp the notion that RIPE is just a sort of ``federal'' system... a federation of a bunch of sometimes waring tribes/states, each with its own separate agenda, and a federation with intentionally limited powers over its constituents. So I'm not really either expecting or even asking them to ``do'' anything about ``piracy''. I will however ask them to look into some of the things that seem wrong to me and that appear in their data base. And I have faith that they will do so, because that _is_ their job. Regards, rfg

3 2

Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002
by Ronald F. Guilmette 06 Nov '14

06 Nov '14

anfernandez(a)lavanguardia.es you wrote: >Let me ask you a question: Which is the mision of RIPE? You didn't ask _me_, but I will answer anyway. The first order mission of RIPE NCC is to make and oversee number re- source allocations, insuring that they are done in an orderly fashion, and to maintain the data base of said allocations. The first order mission of RIPE is to fund and maintain RIPE NCC. >RIPE's web site say: We serve our members by delivering a high quality regi >stry and supporting the core Internet infrastructure. Connecting people wit >hin and beyond the technical community through our inclusive, multi-stakeho >lder approach, we contribute to an innovative and reliable Internet. > >Do you really think RIPE is serving its mission? I do, yes. >Do you really think RIPE is providing a reliable internet? I do, yes. Every time I go to visit, for example, www.bbc.com, it just works. Younger people sometimes don't appreciate what a minor miracle this seemingly simple thing is, and what a colossally large number of different things *all* have to work, and work correctly, in order to make it happen. (I've been working on computers since the mid 1970's, and let me tell you, back then it was _really_ a minor miracle when anything did in fact work.) Regards, rfg

1 0

Hijack Factory: AS201640 / AS200002
by Ronald F. Guilmette 06 Nov '14

06 Nov '14

How does one go about making a formal request to RIPE NCC to investigate a given AS registrant/registration? Given that AS201640 appears to exist exclusively for the purpose of hijacking multiple/numerous blocks of IPv4 space that it rather clearly has no rights to, I would like to formally lodge exactly such a request. http://blogs.cisco.com/security/talos/help-my-ip-address-has-been-hijacked/ http://mailman.nanog.org/pipermail/nanog/2014-October/071056.html This is ongoing, as we speak. Among the many IP blocks being hijacked, one of them even belongs to the Taiwan Network Information Center. Note that the hijacked IP space is being used, perhaps by multiple parties, by also by at least one convicted felon, and for one very specific purpose... http://krebsonsecurity.com/2014/11/still-spamming-after-all-these-years/ Regards, rfg P.S. To be clear, I would like to see there be an investigation of _both_ AS201640 and also the one and only other AS that appears to connect AS201640 to the rest of the world, i.e. AS200002. Somebody please help me here. I did try to read at least one of the official RIPE NCC registration requirement documents yesterday, and I was left with the impression... perhaps incorrect on my part... that in order to obtain an AS, the network in question must be multi-homed. Doesn't that mean that the network in question must have connectivity to the outside world via *more than one* other AS? P.P.S. Unlike RIPE number resource allocations, it _is_ easily possible to find the registration date for most domain names in most TLDs. The AS primarily at issue here is AS201640 and it seems to be associated with a (contact) domain name of "grimhosting.com". (The associated web site, by the way, is _not_ hosted within any IP space which is being announced by AS201640. Rather it is hosted on Cloudflare.) Anyway, the registration date for the domain name grimhosting.com is 2014-06-18. The person name on the registration for both the AS and that domain name is "Bogomil Simeonov". In the domain name registration, this name is associated with the e-mail address <simeonov_zepter(a)abv.bg>. That address in turn seems to be associated with some company named Zepter Bulgaria Ltd., which is apparently a "direct sales" organization, and also, perhaps, with the young man who is pictured in/on this web page: http://cv-simeonov.hit.bg/

3 3

Link to data sets document
by Mirjam Kuehne 06 Nov '14

06 Nov '14

Hi, As promised earlier this week during the WG session, here is the link to the document describing various abuse contact data sets for IT security incident handling: https://github.com/certtools/contactdb/blob/rest/doc/datasets.mkd Please let us know if you have any comments or suggestions. Any feedback is welcome. Kind regards, Mirjam Kuehne

1 0

Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002
by Gert Doering 06 Nov '14

06 Nov '14

Hi, On Thu, Nov 06, 2014 at 03:41:51PM +0000, anfernandez(a)lavanguardia.es wrote: > Let me ask you a question: Which is the mision of RIPE? "Distribute Internet resources in a fair and impartial way to those entities that need Internet resources to go about their business". > RIPE's web site say: We serve our members by delivering a high quality registry and supporting the core Internet infrastructure. Connecting people within and beyond the technical community through our inclusive, multi-stakeholder approach, we contribute to an innovative and reliable Internet. > > Do you really think RIPE is serving its mission? Yes. > Do you really think RIPE database is a high quality registry when the single requirement to the LIRs is not provide untruthful information , but it does not matter if it is unuseful, as, for example, abuse contact email address? If the information provided to the RIPE NCC is not correct, this can lead to closure of a LIR. If someone is not reading their abuse mail, there is nothing the NCC can do about it unless the community(!) mandates it to do so. > Do you really think RIPE is providing a reliable internet? RIPE's delegation of their responsabilities is driving internet to be blocked by a lot of national firewall because of local application of copyright or anti abuse legislaton. Is this the RIPE's reliable internet? The RIPE NCC is not running the internet, but it *is* providing one of the better registration services as far as transparency of policy making and mission go. Especially the fact that it is very clearly defined what the RIPE NCC will do and what it will not do, and that everything can be changed if the community comes to consensus to do so. 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 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

New on RIPE Labs: Security and Privacy Objectives by Geoff Huston
by Mirjam Kuehne 06 Nov '14

06 Nov '14

Dear colleagues, Please find a new article by Geoff Huston on RIPE Labs: Privacy and Security - Five Objectives https://labs.ripe.net/Members/gih/privacy-and-security-five-objectives Kind regards, Mirjam Kuehne RIPE NCC

1 0

RIPE Autonomous System Numbers
by Ronald F. Guilmette 05 Nov '14

05 Nov '14

A few questions, if you don't mind... Given some arbitrary record which is stored within the RIPE WHOIS data base, such as an organization (ORG-*) record or a record for a number resource, such as an AS, how can I determine the date on which that record was created? Do I just look for the earliest date found in any of the associated changed: fields? Give an AS number, issued within the RIPE region, how can I find the identity of the associated LIR? Is the identity of the associated LIR provided by the sponsoring-org: field of the WHOIS record for the AS? What sorts of credentials or bona fides must or should applicants who are requesting AS number allocations provide to the RIPE LIR which processes the request(s)? Has any AS number allocation, issued within the RIPE region, ever been revoked without the consent of the registrant of that allocation? If so, which ones? And in those cases, what policies and/or procedures were used or followed during the revocation process? Are these policies and/or procedures written down someplace, or are they entirely ad hoc?

10 28

Revised Minutes, RIPE 68
by Brian Nisbet 05 Nov '14

05 Nov '14

Colleagues, It was pointed out in the meeting today that there were mistakes with the previous minutes and we've discovered that an important section or two were missing. Below I have pasted the new version of the RIPE 68 minutes, including the conversation about LEA attendance at RIPE related meetings (Section D.3). If you could take a look at these that would be great. Also, if I could ask the NCC to look at the possibilities around the action that was assigned to them in that section. Thanks, Brian *********************************** === A. Administrative Matters Brian welcomed the participants to the Working Group session and introduced himself and Tobias as co-chairs. and thanked the RIPE NCC for providing support in the form of chat monitor, scribe and stenographers.  The minutes from RIPE 67 and RIPE 66 were approved and there were no additions to the agenda. B. Update Brian asked the room if there was anything pertaining "abuse-c:" that needed to be raised. As nobody spoke up, Brian stated that it could be covered later on if needed.  Brian mentioned that he had circulated some text for the working group charter. He noted that there had been some discussion but was happy to keep any discussion on the list. He invited the room to make any comments there and then if needed.  There were no comments.  Brian urged the participants to read the charter on the mailing list. C. Policies Brian stated that there were no open policies at the moment. D1. Interactions With Other Working Groups Regarding interactions with other working groups on policy, Brian noted that he and Tobias had agreed with Nigel Titley and Wilfried Wober, the Database Working Group Chairs, that he and Tobias would work on the data verification policy. He mentioned that he and Tobias would not have time for this soon, and therefore urged participants that, should they want to take on the task, they were welcome. D2. Proof of identity discussions – RIPE Policy Proposal 2007-01 There was some discussion about the level of proof of identity that the RIPE NCC should expect.  Athina Fragkouli, RIPE NCC, stated that this was also discussed in the Address Policy Working Group and there were not many concerns about how the RIPE NCC handles proof of identity. She added that the RIPE NCC is always open to changing procedures.  Brian asked the room whether the RIPE NCC are doing enough, too little, or to much regarding proof of identity. He asked if there should be more trust.  Jim Reid, unaffiliated, felt that things should be left as they are. He expressed that he thought it was bad to collect personal data unless there is a strong need for the data. However, he can appreciate the RIPE NCC's point and can see how it's useful in some cases, such as for law enforcement and other aspects of anti-abuse. Brian agreed that it's okay for the RIPE NCC to continue as it is. D3. RIPE NCC Government/LEA Interactions Update -Marco Hogewoning, RIPE NCC The presentation is available online: https://ripe68.ripe.net/presentations/387-AA-LEA-Update-MH1_AG.pdf Alexander Isavnin, NetLine, asked if it was possible for a Dutch membership organisation to join closed meetings and not reveal what was discussed. Marco responded that he thought it was possible. Alexander stated that the community wants to know what happens at these meetings and urged for no secrecy. He wanted to know the name, rank, and position of those attending these meetings with law enforcement. Marco stressed that these meetings are with law enforcement agencies (LEAs), not with the intelligence community. Alexander responded that name, rank and position will support that the attendees are not from the intelligence community. Marco responded that the RIPE NCC is looking at a way to improve the reporting but needs to work with LEAs about the information that can be published. He added that it may be possible to publish attendee lists and or give more information about the attendees, however, it's important that the trust level is maintained between the LEAs and the RIPE NCC. Alexander responded that he wants European interaction to be more clear. Jochem De Ruig, RIPE NCC, stated that Brian Nisbet is invited to these meetings so that he can provide input from the community's perspective. Brian added that he has been asked by someone from the National Crime Agency (NCA) to remove their name from a public agenda as their friends and family did not know with whom they were employed. Brian felt that there would not be much cooperation if a full list of attendees was to be published. Malcolm Hutty, LINX, added that it's about balance and satisfying all parties reasonably. With some advance planning, he feels that basic information could be disclosed and some transparency added. He added that it would be best to avoid mentioning whether anything operational was discussed (or not). He also noted that some individuals would probably need their names kept secret and off lists, and therefore it may make sense to ask them if the name of their organisation could be published. Brian agreed that he fully advocates transparency and agreed with the need for balance. Jim Reid agreed with Malcolm, and urged for more forward planning. He also added that he felt it would be wrong to disclose the name, rank and identity of everybody attending a meeting because that, in itself, could disclose operational details. Marco concluded that that he will take this back to law enforcement and work with them on future events to achieve better reporting. E1. "Anti-Abuse: The View from the Messaging World" -Jerome Cudelou, M3AAWG The presentation is available online: https://ripe68.ripe.net/presentations/373-M3AAWG.pdf  Brian asked whether there are any more areas of mutual engagement that could be touched upon.  Jerome responded that it would be best to become members of M3AAWG.  Brian asked whether non-members of M3AAWG could contribute to M3AAWG’s documentation.  Jerome responded that he didn’t think it was easy to do and that it is better to become a member.  Rüdiger Volk, Deutsche Telekom, asked if there were documents that would explain what is expected of an abuse contact.   Jerome responded that the document is under discussion.  Vincent Schonau, abuseix and co-chair of the Training Committee at M3AAWG, further clarified that there is the Abuse Desk Best Practises document that is now a few years old. He added that the Abuse Desk Special Interest Group has revived the document and would work on it in upcoming meetings.  Alex de Joode, LeaseWeb, stated that LeaseWeb is not a member of M3AAWG but are participating in the Hosting Special Interest Group (SIG) and the Abuse SIG so participation is possible without becoming a member.  Brian asked Alex what the procedure was for participation.  Alex responded that he had sent a message to Gerry Upton and received a free invitation.  Samaneh Tajalizadehkhoob, Delft University of Technology, asked if M3AAWG cooperate with research institutions. She mentioned that Delft University of Technology are working on banking malware and mobile malware, and asked if M3AAWG share data with them.  Jerome responded that they do share data with research institutions.  Vincent noted that M3AAWG has a very open policy about inviting people to come to the European meetings and the emerging groups such as the Hosting SIG. He directed interested parties to Gerry, Jerome or himself for an invitation.  Brian asked an open question to RIPE NCC members in the room whether there had been any interaction with M3AAWG since RIPE 45 in Barcelona.   Jochem de Ruig, RIPE NCC, responded that the RIPE NCC would try to come to Brussels and that the RIPE NCC did find the meeting useful for engagement with the community. E2: Impact of abuse-c -Bengt Gördén, Resilans  The presentation is available online: https://ripe68.ripe.net/presentations/383-impact_abuse-c.pdf  Ruediger asked whether the message to the abuse-c at Spamhaus was successful.  Bengt replied that it was not, and asked if there were questions about that.  Ruediger continued, adding that Spamhaus is bullying people on the Internet and that a joke he had heard is that it may be possible to send a claim of copyright or trademark infringement with the name Spamhaus and send it to .org.  Bengt added that it would work.  Ruediger added that the Internet community needs to make sure that things are balanced out, thanking Bengt for his presentation.  Erik Bais, ATB Internet, added that they had been in the same situation with Spamhaus and it had been well-documented.  Bengt responded that he had read about it.  Erik continued that they had disclosed fully about their interactions with Spamhaus, who had behaved brazenly in return, finding the situation amusing and even blogging about it on their website. Erik added that Spamhaus do not care and that they have been invited to the RIPE Anti-Abuse Working Group sessions, to have a panel and discuss the proper policies, but had refused the invitation.  Brian added that that the relations between the Working Group and Spamhaus were not as good as they would like, and redirected the discussion back to “abuse-c:”.  Erik stated that they transferred some of their address blocks and even after six months they still receive emails to their abuse mailbox regarding blocks that they don’t own anymore. He called for people to use the RIPE Database and asked how it is possible to make people update their information.  Bengt replied that he feels the community needs to work on this issue collectively, but not necessarily in a way that results in any legislation or policy.  Erik added that it’s good to remember that Spamhaus does not block mail and there is always a need for well-managed block lists.  Peter Koch, DENIC, asked Bengt about his slides as they seemed somewhat contradictory to him, as they looked more like a “suffering story” rather than a success story and he did not understand why it was being used as an example, as Bengt’s “I told you so.”  Bengt responded that maybe it is time that they give up on optimising the “abuse-c:” for an audience that cannot be educated.  Brian invited Tobias Knecht, his fellow chair of the Anti-Abuse Working Group to comment on similar policies in other regions.  Tobias stated that the policy about “abuse-c:” was brought into APNIC in a different way, as well as at AFRINIC. While the implementations were different, the end result was the same - that there is an abuse contact in the Whois Database, a single space.  Bengt noted that he had tried to get an abuse contact for Spamhaus and it hadn’t worked.  Alex Le Heux, Kobo Inc, added that they had similar experiences with many of those blacklists. He stated that Spamhaus regularly attends M3AAWG and advised those who wanted to meet with them, to go to the Brussels meeting. He invited those with similar experiences to come to the meeting so that some sort of best practises for blacklists can be set up.  Brian confirmed that a best practises document that has come out of M3AAWG already exists. E3: Abuse-c: Next Steps for “abuse-c:” -Denis Walker and Christian Teuschel, RIPE NCC  The presentation is available online: https://ripe68.ripe.net/presentations/162-aa_wg.pdf  Brian noted that time was running short, and some discussion may need to be directed to the mailing list.  Ruediger asked if it was explained anywhere how ORGANISATION objects should be used.  Denis responded that it was one of the big problems with the RIPE Database.  Ruediger noted that there is no documentation and explanation of the data model that the RIPE NCC says that the community should be following.  Denis replied, saying that no business rules were built into the software to enforce any of this, and agreeing that there are no guidelines.  Ruediger argued that, if there is a data architecture that should be followed, it should be documented and agreed upon. He called for a document that explains what the architecture is.  Brian asked whether this discussion would be something better suited to the Database Working Group.  Peter thanked Denis and Christian for their hard work. He noted that the RIPE Policy Development Process allows early and often objections and he believes that they are at risk of going completely overboard in a variety of aspects. He stated that he thinks that the model is in the wrong direction, and he is opposed to “salami tactics”. His interpretation of one of the slides is that there is an ORG object and the addresses hang off it, and he cannot find any document that describes it that way. The database model with which he is familiar is one built around the objects you ask for, and the information attached to the objects, in other objects. He called for changes to the model. He added that if this were moved to the Database Working Group, that would only partly help as the changes proposed from the Anti-Abuse Working Group may not be compatible with the Database Working Group point of view.  Brian clarified that, if there were issues with the architecture and business rules and documentation, then it would be more appropriate for the Database Working Group to work with the RIPE NCC to get that written.  Peter stated that it may be time to reconfirm the mission of the RIPE Database, adding that it should not become a “compliance stick” for Local Internet Registries or resource holders.  Christian asked Peter what he had meant by “salami tactic” regarding the validation.  Peter clarified that having a mailbox does not mean that mail is delivered or read. The next slice of salami is to validate, so that mail can be expected to be deliverable. He envisioned that, three months later, it won’t only be deliverable, but there would be a reply.  Christian replied that this is what they had proposed, improving the data quality.  Peter added that caution would need to be taken when regarding data quality as it is a topic for the admin-c and the resource holder. He believes that the data should be correct because that is the core mission.  Via remote participation, Gilles Massen asked if, as the existing IRT objects are becoming more invisible, would it be possible to reference an IRT from the “abuse-c:” or at least add the useful IRT features like BGP keys to the “abuse-c:”. He stated that he would like to see relaxed constraints like a copyright-abuse-mailbox: NULL for signalling that one should not expect a reply to those sorts of messages. He also asked that IRT objects not be touched without prior discussion in the Working Group.  Denis responded that the RIPE NCC understands that the IRT object is not very popular and that they have been asked to propose to the community as to how the IRT could be made more useful. He will provide feedback to the Working Group for further review.  Piotr Strzyżewski, Silesian University of Technology, referred to Bengt's presentation, noting that some of these corporations don't care about the "abuse-c:" and therefore it wouldn't be useful to establish another point of contact for them. He sarcastically added that he “loves" the idea of national responsibility (with the opposite being his true feelings on the matter). However, he does feel that there should be some policy regarding validation.  Christian responded that he thinks validation and extending the ROLE object should go through the RIPE Policy Development Process.  Brian stated that he thinks it must go through that process.   Christian continued, stating that extending the ROLE object is something that has come from the community. While he acknowledges that some countries have more than one national CSIRT, the implementation needs to be clear and the list of contact details for all of them should be provided. He added that the RIPE NCC is trying to work with them, in the case that the “abuse-c:” fails.  Brian asked about the origin of the request from the community.  Christian replied that it hadn’t come from the mailing list, and had come from a meeting of the computer security community.  Kaveh Ranjbar, RIPE NCC, added that the provision of a proper abuse contact was a recurring point in the RIPE NCC Survey 2013’s results and therefore the RIPE NCC had started to attend security conferences.  Ruediger asked Christian if the CSIRTS were happy about getting the reports, or if they were unhappy.  Christian replied that they were happy.  Ruediger expressed doubt and surprise that they would be happy to be “flooded” by copyright abuse reports. He called for guidelines and information as to what kind of report people should be sending to abuse contact, and how people should be responding to these reports.  Denis added that, if Ruediger wants the RIPE NCC to provide these guidelines, then the community should provide the text.  Ruediger agreed with Denis that this is a task for the Working Group.  Brian added that he was surprised that the CSIRTS were happy, and noted that many countries don’t have a CSIRT. He added that he would put out a call for volunteers to help work on the guidelines.  Ruediger added that, without guidelines, doing validation beyond mechanics is meaningless. E4: Introduction to Contact Databases for Abuse Handling -Aaron Kaplan, nic.at Aaron explained how they do contact lookups at csirt.at, a national CSIRT for Austria. He noted that a national CSIRT is usually just a router for abuse contact information and that there are different approaches in different countries. Aaron asked those involved with the RIPE Database to have IRT objects, “abuse-c”, etc. as specific and up-to-date as possible as it will help those sending information to national CSIRTS for lookups.   Brian asked where the information about Aaron’s presentation would be available and if he could publish it to the list.   Aaron added that it is a document on Github.  Brian asked if he could email the list with the URL.   Aaron replied that it is part of a document that Christian Teuschel and Mirjam Keuhne, RIPE NCC, and Wilfried Woeber started. It is connected to a GitHub project called GitHub.com/CERTtools that is a contact cache/contact database for national CSIRTs so that they can build on the process.  Brian added that it might be good to discuss this in more depth at a future RIPE Meeting.  Aaron stated again that the CSIRT is just acting as a router, passing copyrights through, and the copyrights end up with network owners under their policies. However, he noted that the routing process can be optimised.  There were no further questions or comments.  Brian thanked Aaron for his presentation and invited the room to contribute agenda items for RIPE 69 in London. He thanked the scribe, speakers, stenographers and participants before closing the session.

2 1

Final Draft Version - Appointment & Removal of AA-WG Chairs
by Brian Nisbet 04 Nov '14

04 Nov '14

Colleagues, Apologies for the long delay on this, here is some very slightly revised text. It hasn't diverged much from the text of the 26th of September, but I've taken into account a number of comments that were made, especially around language. It is still my intention, at least initially, to limit this to the people in the room at a WG session at a RIPE meeting, but obviously this is up to the WG, so we can discuss this tomorrow. ************** Note on Language: Throughout this document the word Chair shall be used for both Chairs and Co-Chairs. ** Introduction: This document outlines procedures dealing with the tenure of RIPE Working Group Chairs. It applies to all RIPE Working Groups. ** WG Chair Term: The term of a WG Chair is three years. A current chair may stand for re-selection at the end of their term. A WG Chair may resign voluntarily at any time. ** Selection of a WG Chair: WG Chair vacancies, along with a call for candidates, must be announced on the WG mailing list at least one month in advance of the date upon which the selection will be held. The announcement should set a closing date for candidates. A WG may request that a WG Chair vacancy be opened so long as the addition of a new Chair would not cause the number of Chairs of that WG to exceed three. WG Chairs are elected at WG sessions at RIPE meetings. Anyone physically present at the WG session is eligible to participate in the selection process. The candidate does not need to be physically present at the WG session. If possible the Chair should be elected by acclamation by the WG or by consensus after discussion. If the result is unclear, then a secret ballot should be held. In the case of a ballot, votes will be counted by RIPE NCC Staff and/or Chairs of other WGs. The result will be determined by simple majority. ** Removal of a WG Chair: A WG Chair may be unable to fulfil their duties as described in this document or otherwise fail to serve the WG and the community. With the endorsement of a significant share of the WG, a vote of no confidence may be initiated. Before a vote of no confidence is taken, due effort should be made to address the issue(s) leading to the vote. The right of reply must be given to all parties involved in the procedure. If this effort fails to resolve the issue, the vote may proceed. The vote must be requested on the WG mailing list at least one week in advance of the WG Session at a RIPE meeting and should take place during the WG session. Anyone physically present at the WG session may take part in the vote. The vote should be conducted by secret ballot and votes counted by RIPE NCC Staff and/or WG Chairs of other WGs. The result will be determined by simple majority. If the vote of no confidence in a WG Chair is passed, the seat is vacated and the WG Chair is not eligible for stand for re-selection. ** No Chair: If a working group is left with no Chair, e.g. due to the resignation or removal of the sole WG Chair, then the WG may elect an interim WG Chair according to the selection procedures specified above, but with candidates nominated at the WG session. An interim WG Chair must resign at the next WG session, but may stand for re-selection. ** Staggered Introduction: For the purposes of staggering the introduction of this policy, in the case where all co-Chairs of a WG have served for more than the standard WG Chair term limit, an optional waiver is given to these WGs to allow them to schedule the automatic resignations of their Chairs over the two RIPE meetings immediately following the adoption of this policy. If the WG decides to avail of this waiver, it is the responsibility of the WG to decide in what order its co-Chairs should stand down.

2 2