This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/anti-abuse-wg@ripe.net/
[anti-abuse-wg] Hijack Factory: AS201640 / AS200002
- Previous message (by thread): [anti-abuse-wg] Hijack Factory: AS201640 / AS200002
- Next message (by thread): [anti-abuse-wg] Hijack Factory: AS201640 / AS200002
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ronald F. Guilmette
rfg at tristatelogic.com
Thu Nov 6 21:03:18 CET 2014
In message <545B8542.9010203 at ripe.net>, Laura Cobley <laura at ripe.net> wrote: >Dear Ronald and all, > >The RIPE NCC investigates reports about Internet number resource >registrations. These fall into different categories: > >- Violation of RIPE Policies and RIPE NCC Procedures >- Provision of untruthful information to the RIPE NCC >- Bankruptcy, liquidation or insolvency >- Incorrect contact information in the RIPE Database > >You can read more about the procedure together with a link for >submitting a report at: https://www.ripe.net/contact/reporting-procedure Thank you Laura. This information is really most helpful. As should be apparent, I would like to file a report on AS201640, but I believe that I may need some help with that, from you, from the members of this mailing list, or both. This is not a case involving any kind of bankruptcy, so that one (out of four) is clearly inapplicable. But with regards to the remaining three possibilities, I could use some guidance. Let's take them one at a time. (*) Violation of RIPE Policies and RIPE NCC Procedures I asked the list about this earlier. Is there a requirement that an AS be ``multi-homed'' and does AS201640 currently appear to be fulfilling that requirement? Could some list participants who know more than me on this point... which is to say just about everybody... please comment and enlighten me? (*) Provision of untruthful information to the RIPE NCC Here again, I need to ask for guidance. Last night, I did see several things... things in the RIPE WHOIS data base... that did seem entirely wrong to me. If one queries the RIPE WHOIS data base, right now, about any of the following IP addresses, you will see what I mean: 105.154.248.0 210.57.0.0 202.39.112.0 119.227.224.0 41.198.224.0 The responses that come back from the RIPE WHOIS server say that each of the above IP addresses belongs to "MEGA - SPRED LTD". I believe that these responses are all incorrect however, and that in fact, none of the relevant IP ranges is actually, formally, and properly registered to either "MEGA - SPRED LTD" or to -any- entity within the RIPE region for that matter. (The addresses in question belong to other RiRs. So sayeth IANA.) So there are two seemingly obvious questions: 1) Did these RIPE data base entries come about because "MEGA - SPRED LTD" ``provided untruthful information to the RIPE NCC''? I can't tell. I guess that it largely depends upon one's definition of ``untruthful''. It *is* in fact true/truthful that AS201640 *has* in fact been announcing routes to the relevant blocks of IPv4 space. But it is my contention that they have no rights to do so. If true, would that situation imply untruthfulness... actionable or otherwise... on on that part of AS201640? 2) How on earth did these RIPE IPv4 block registration records even manage to get in to the RIPE WHOIS data base anyway?? As I have said, the IP blocks in question all seem to belong to other RiRs. That is what the whois.iana.org WHOIS server is telling me anyway. Does the RIPE WHOIS data base routinely contradict the IANA data base in this way? Is it _supposed_ to do so? Does any checking occur on newly added RIPE WHOIS records... before they go into the RIPE WHOIS data base... to make sure that no such newly added RIPE WHOIS records conflict with what IANA believes (regarding number resource allocations)? If not, why not? And if so, how did the five examples above slip past these simple consistancy checks? (*) Incorrect contact information in the RIPE Database I gather that this one is intended to deal with contact data that, while once having been accurate, has not been properly maintained, over time. So I guess that this doesn't apply to the present case either. Regards, rfg
- Previous message (by thread): [anti-abuse-wg] Hijack Factory: AS201640 / AS200002
- Next message (by thread): [anti-abuse-wg] Hijack Factory: AS201640 / AS200002
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]