Brian Nisbet <brian.nisbet@heanet.ie> wrote:

There's no webform for this, no, but if you email ncc@ripe.net and/or abuse@ripe.net, this should get things to the right person and it can go from there.

Given the number of cases I've reported to RIPE, and the apparent inaction, I'm not convinced that either of those would be a viable communications channel. Perhaps we do need a webform. No doubt the RIPE NCC will protest that since there isn't a policy that tells them to actually do anything about such cases, there's no point us having a webform anyway. -- Richard Cox

Hi,

...

...

There's no webform for this, no, but if you email ncc@ripe.net and/or abuse@ripe.net, this should get things to the right person and it can go from there.

Given the number of cases I've reported to RIPE, and the apparent inaction, I'm not convinced that either of those would be a viable communications channel. Perhaps we do need a webform. No doubt the RIPE NCC will protest that since there isn't a policy that tells them to actually do anything about such cases, there's no point us having a webform anyway.

Hummm... OK. I didn't realize things were that bad.

It is! ;-)

So, ah, maybe the Right Place To Start would be for somebody (perhaps even this working group?) to propose at least some sort of a policy (e.g. on hijacked ASNs and/or address blocks) for RIPE's consideration (?)

I do agree that in the absence of any policy to even investigate, a web form for submissions isn't going to help a lot.

I have done a policy proposal for APNIC which was discussed in the last meeting, but didn't find consensus. See more about this here: http://www.apnic.net/policy/proposals/prop-084 I think we should change that a bit and say: "RIPE is responsible to keep up accuracy for the data held in the whois database!" The means that RIPE has to find ways to do so. The above mentioned proposal by the way is in a similar way in process at ARIN. If this working group thinks the policy proposal would be nice for RIPE, let me know and I will make the needed changes. Thanks, Tobias

Hi all, Isn't LIRs already subject of auditing? Is the frequency of auditing too low perhaps? If Ripes new abusefinder tool isn't sufficient enough I am sure they welcome feedback. It is quite funny that the term webform has been brought up. Previous abuse-discussions had topics like "we want to require every abuse contact to be reachable by email". This only tells me that there will never ever be any consensus about abuse contact methods or standards this century. I have no idea of the RIPE country restrictions, but forcing a LIR to go to a certain RIR when requesting resources - isn't that monopoly? Since when is that good for anyone? I don't really want a public database of our LIRs allocations with timestamped inetnums that goes back in time. If you want that kind of information you can contact us directly, and if you do I might tell you to contact the authorities first to get a warrant. I can't think of very many reasons, if any at all, why you would need such information without it having something to do with illegal activities anyway. And that is someone elses job. We sometimes receive contact information requests from the authorities. We receive these requests even though the contact information is already available in the RIPE db or a simple webbrowse to the IP-adress return the companys website with full contactinfo. I am pretty sure this will never change even if RIPE was forced and punished to make sure their database was correct. So in my country, a public RIPE database with end-user allocation information is probably only good for spamming. I would rather see it more restrictive supporting internal identificators that can be used in some sort of report system to a particular LIR instead of requiring real contact information which is constantly subject to change anyway. J On 09/29/10 09:01, Aftab Siddiqui wrote:

Hello Tobias, yes, to my surprise as well the proposal didn't reach the consenses at APNIC. But in my personal experience most of the abuse reports we send are undelivered due to bad/incorrect address. The reason for policy or web reporting is there, lets see if majority acknowledges it or not.

Regards,

Aftab A. Siddiqui

2010/9/29 Tobias Knecht <tk@abusix.com <mailto:tk@abusix.com>>

Hi,

>>> There's no webform for this, no, but if you email ncc@ripe.net <mailto:ncc@ripe.net> >>> and/or abuse@ripe.net <mailto:abuse@ripe.net>, this should get things to the right >>> person and it can go from there. >> >> Given the number of cases I've reported to RIPE, and the apparent >> inaction, I'm not convinced that either of those would be a viable >> communications channel. Perhaps we do need a webform. No doubt >> the RIPE NCC will protest that since there isn't a policy that tells >> them to actually do anything about such cases, there's no point us >> having a webform anyway. > > Hummm... OK. I didn't realize things were that bad.

It is! ;-)

> So, ah, maybe the Right Place To Start would be for somebody (perhaps > even this working group?) to propose at least some sort of a policy > (e.g. on hijacked ASNs and/or address blocks) for RIPE's consideration (?) > > I do agree that in the absence of any policy to even investigate, a web > form for submissions isn't going to help a lot.

I have done a policy proposal for APNIC which was discussed in the last meeting, but didn't find consensus. See more about this here: http://www.apnic.net/policy/proposals/prop-084

I think we should change that a bit and say: "RIPE is responsible to keep up accuracy for the data held in the whois database!" The means that RIPE has to find ways to do so.

The above mentioned proposal by the way is in a similar way in process at ARIN.

If this working group thinks the policy proposal would be nice for RIPE, let me know and I will make the needed changes.

Thanks,

Tobias

On Wed, Sep 29, 2010 at 12:35:10PM -0700, Ronald F. Guilmette wrote:

Take that ``Belize'' block I pointed out earlier. Let's just say, hypothetically, that there was some criminal activity going on in there. Who should I report that to? Who should investigate? Belgian police? (home of RIPE) Belizian police?[1] Interpol??

Dutch, not Belgian. Regards -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl

Hi, On 29/09/2010 21:35, Ronald F. Guilmette wrote:

Take that ``Belize'' block I pointed out earlier. Let's just say, hypothetically, that there was some criminal activity going on in there. Who should I report that to? Who should investigate? Belgian police? (home of RIPE) Belizian police?[1] Interpol??

I'm afraid I don't know, and I really don't care about cybercrime outside my own country. As a private person/non-governmental I don't understand why you care either. There are too many different laws in different countries and I can't even see that the Belize block have broken any in theirs with their "lovely" pillshop (Romania or not). But it is, and should be, perfectly legit to have contactinformation pointing to Belize if you are Danish and live in Denmark as long as the contactinformation works. There are also many proxy companies selling services like that. If this is about spam then surely you must be having a spamfilter. Cheers, J

Hello,

yes, to my surprise as well the proposal didn't reach the consenses at APNIC. But in my personal experience most of the abuse reports we send are undelivered due to bad/incorrect address. The reason for policy or web reporting is there, lets see if majority acknowledges it or not.

I will publish some of those policy proposal within the next days on this list. So stay tuned. Thanks, Tobias

In message <4CA25A63.3090608@abusix.com>, Tobias Knecht <tk@abusix.com> wrote:

...

So, ah, maybe the Right Place To Start would be for somebody (perhaps even this working group?) to propose at least some sort of a policy (e.g. on hijacked ASNs and/or address blocks) for RIPE's consideration (?)

I do agree that in the absence of any policy to even investigate, a web form for submissions isn't going to help a lot.

I have done a policy proposal for APNIC which was discussed in the last meeting, but didn't find consensus. See more about this here: http://www.apnic.net/policy/proposals/prop-084

That proposal seems quite reasonable. What were the objections? Is it appropriate to assume that the main objections were to this part? - After the 60-day period has passed, if the object owner has not verified their object details, APNIC will add the ranges of resources maintained by the non-responsive object owner to the publicly available list of resources described in 4.5.1 below. Regards, rfg

Ronald If we were putting servers in the US we would probably have to get an AS number and allocation from ARIN. We also would have non-EU clients with RIPE space. Regards Michele Mr. Michele Neylon Blacknight http://Blacknight.tel Via iPhone so excuse typos and brevity On 28 Sep 2010, at 22:06, "Ronald F. Guilmette" <rfg@tristatelogic.com> wrote:

In message <A.1P0dJI-000Kvu-EO@smtp-ext-layer.spamhaus.org>, you wrote:

...

Brian Nisbet <brian.nisbet@heanet.ie> wrote:

...

There's no webform for this, no, but if you email ncc@ripe.net and/or abuse@ripe.net, this should get things to the right person and it can go from there.

Given the number of cases I've reported to RIPE, and the apparent inaction, I'm not convinced that either of those would be a viable communications channel. Perhaps we do need a webform. No doubt the RIPE NCC will protest that since there isn't a policy that tells them to actually do anything about such cases, there's no point us having a webform anyway.

Hummm... OK. I didn't realize things were that bad.

So, ah, maybe the Right Place To Start would be for somebody (perhaps even this working group?) to propose at least some sort of a policy (e.g. on hijacked ASNs and/or address blocks) for RIPE's consideration (?)

I do agree that in the absence of any policy to even investigate, a web form for submissions isn't going to help a lot.

Meanwhile, on a related topic...

Now that people here were kind enough to point me at the -B option for the RIPE whois server, I did manage to get a tiny bit more information about that Belize-domiciled network (INSTANTEXCHANGER-NET) that I mentioned earlier:

% fgrep ' 20' INSTANTEXCHANGER-NET changed: hostmaster@ripe.net 20100414 changed: sp@instant-exchanger.com 20100410 changed: sp@instant-exchanger.com 20100410

% fgrep ' 20' AS50877 changed: hostmaster@ripe.net 20100414 changed: sp@instant-exchanger.com 20100410 changed: sp@instant-exchanger.com 20100410

So it would appear that I may have been correct, and that this ``European'' oddity was issued only just earlier this year... in April to be precise.

Short of traveling a long distance by plane and showing up physically to the next RIPE meeting, is there any way for me to find out why an ASN (AS50877) and also a non-trivial amount of IPv4 space (195.80.148.0/22) would have been assigned by RIPE staff to a company that, according to the RIPE whois records themselves, is domiciled in Latin America?

(Separate question: Is there any way to obtain archived dumps of the RIPE whois data base, e.g. from April of this year, so that I might be able to check and see if the original whois for the AS & IP block also said "Belize", as I suspect it did?)

Certainly, if RIPE is not responding at all to reports of hijackings of pre-existing & previously allocated ASNs and/or IP blocks, then I would say that that is certainly a problem. But this whole Belize thing is different, I think, and perhaps in some ways worse. Why would anyone bother to hijack an IP block or an ASN if RIPE will just issue you either of those things, willy nilly, no matter where you live?

Regards, rfg

Ronald F Guilmette <rfg@tristatelogic.com>

Hummm... OK. I didn't realize things were that bad.

Unfortunately, as has been confirmed by others, they certainly are!

So, ah, maybe the Right Place To Start would be for somebody (perhaps even this working group?) to propose at least some sort of a policy (e.g. on hijacked ASNs and/or address blocks) for RIPE's consideration

We do need a number of policies to help redress the balance on abuse. A Working Group cannot propose a policy, a member has to propose a policy. I had been thinking of proposing several, as I made clear in my report at the AAWG in Prague. The limitations are time and my inexperience (I have never worked through that process before), plus I'm somewhat discouraged from doing it by the resistance I encounter from RIPE NCC staff when pursuing these issues. In other words, even if there were such policies agreed through the PDP, it seems to me possible that the NCC staff might find some way to ensure that the policies as agreed do not end up having the effect that we want. The other problem is the obvious Conflict of Interest. Although the policies I believe should be proposed, would gain considerable support in this Working Group, there is no guarantee that the decision would be allowed to be made in this Working Group. Other Working Groups have legitimate interests in the areas of concern (such as Address Policy, Database, etc) and their members may be less supportive as in some cases their existing freedoms (which are being abused by only a small number of LIRs) would then need to be reined in for all LIRs. The decision as to where each policy proposal is discussed and agreed, is made by the Working-Group Chairs collective. Brian Nisbet and I are obviously members of that collective, but we have to overcome the hurdle that no Policy proposal that impacts on what the RIPE NCC do, has ever (as far as I can see) been put through the Policy Development Process within the AAWG or its predecessor, the ASWG. Additionally if I were the actual proposer of a policy, I would be unable to contribute to that (or any related) decision-making-process. Which is why I'd be a lot happier if other participants would consider making proposals.

Short of traveling a long distance by plane and showing up physically to the next RIPE meeting, is there any way for me to find out why an ASN (AS50877) and also a non-trivial amount of IPv4 space (195.80.148.0/22) would have been assigned by RIPE staff to a company that, according to the RIPE whois records themselves, is domiciled in Latin America?

Well, WE have to travel long distances by plane every time there is a RIPE meeting ;-) But (a) you wouldn't be likely to get any meaningful information by attending in person (the answer to "why" will doubtless be that "a RIPE LIR submitted an application which appeared to comply with the relevant policy and so the allocation was made") And for the record, policy decisions are only made in RIPE Working Groups, and not at RIPE meetings. The only decision-making part of a RIPE meeting such as is coming up in Rome in November, would be the RIPE Members' meeting. RIPE Members are limited to the LIRs, and not the likes of you or me.

(Separate question: Is there any way to obtain archived dumps of the RIPE whois data base, e.g. from April of this year, so that I might be able to check and see if the original whois for the AS & IP block also said "Belize", as I suspect it did?)

Have you been introduced to the RIPE Resource Explainer yet? See: http://albatross.ripe.net/cgi-bin/rex.pl It does not show the original WHOIS data (sadly) but it can be helpful. We can be reasonably sure that the resource holder for 195.80.148.0/22 is not in Belize because the phone numbers in the WHOIS record are in an invalid format for Belize. (See: http://wtng.info/wtng-501-bz.html) If they really were in Belize, they would know the local phone number format and so even if they wanted to submit fake phone numbers, they would probably get them in the correct format. Incidentally, we see that CIDR currently routing to Starnet, Moldova. No surprise there. But the BGP PATH downstream of Starnet (AS31252) is most unusual: "31252 12968 40975 41665 30968 50877" which tells us that packets are (allegedly) passing through routers announcing these networks: AS31252 STARNET MOLDOVA AS12968 CROWLEY DATA POLAND AS40975 CHML WEB SERVICES ROMANIA AS41665 HOSTING.UA UKRAINE AS30968 INFOBOX.RU RUSSIA AS50877 INSTANTEXCHANGER "BELIZE" But what may well be an ICMP filter at Starnet prevents traceroutes. I think what we are seeing here is an ASN simulator, similar in concept to the traceroute simulators that have been used by the Russian Business Network. It is probably being used as part of a non-physical routing technology, such as BGP-VPN. If you go to route-views.routeviews.org, log in, and issue "sh ip bgp regex 12968" (without the quotes, natch!) Routeviews will show you all routes that have been contributed to Routeviews which allegedly pass through AS12968. It takes some time to get usable data from Routeviews' output but when you do you will see that the upstreams for AS12968 are AS1299, AS2914, AS3356, AS6939 and AS9002: there is no mention of AS31252 except for routing to AS40975 et al, and for one other /24 (which is also suspect). Now it is entirely possible for some Routeviews data to be misleading (not through any fault of Routeviews, but anyone who understands BGP will know what I'm referring to) and it's also possible for the above to happen for legitimate reasons, so other checks were needed to make certain that my results are meaningful: those checks have been done and they passed: I'm not going to post details for obvious reasons. Similarly, querying Routeviews for announcements transiting AS40975 tells us that AS40975 has just two upstreams: AS5606 and AS8751, but for the single route that ends up at AS50877 it has an extra upstream AS12968. Its own IP ranges are not announced to AS12968 (and it has no downstream customers) For the record, upstreams of Starnet are: [AS2905|AS3257|AS3267|AS3549|AS5459|AS6939|AS8218|AS13101|AS16150]

Why would anyone bother to hijack an IP block or an ASN if RIPE will just issue you either of those things, willy nilly, no matter where you live?

The only advantages of hijacking a block in the RIPE service region are (a) that you would then avoid having to pay for it, and (b) that your conscience would be less likely to be troubled by the fact that some LIR had taken your money for submitting (probably) exaggerated information about your hardware etc to the RIPE NCC on your behalf. -- Richard Cox Co-Chair AAWG

Hi, On Wed, Sep 29, 2010 at 03:33:21PM +0000, Nigel Titley wrote:

I'd like you to clarify some of the statements you made below:

1. "A Working Group cannot propose a policy, a member has to propose a policy."

I'm not sure where you got this idea. I thought that in the meeting you had with Axel, Remco, Rob and myself we made it abundantly clear that anyone can propose a policy. You can walk in off the street and propose a policy if you want.

Well, the fine line is "the WG proposes something" vs. "a natural person (member of the WG or otherwise) proposes something" So I think you are both right - the PDP wants to tack a name of the person who is proposing something onto the paperwork, but that person can be anyone. (And, of course, I agree that the usual suspects are usually quite willing to help with procedural questions regarding policy changes. AA policy is new territory for all of us, so we all will learn something...) Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

In message <A.1P16gH-0009if-Lx@smtp-ext-layer.spamhaus.org>, Richard Cox <richard.cox@btuser.net> wrote:

However since you are reading this thread, and given your extensive knowledge of BGP and routing, would you like to comment on the point that gave rise to it, namely the fraudulent misuse of RIPE resources?

That description of that incident may sound as if it was a one-off. It's not. In fact it is part of a pattern that we see almost on a daily basis. Always involving RIPE ASNs and IP ranges. Never ARIN. Never APNIC. And not even AFRINIC or LACNIC.

Although I do believe that Richard Cox and I most probably share the same views on many many things, I do feel obliged to differ with him as regards to this last comment. In my own experience, there do exist quite a substantial number of ARIN whois records which, as we speak, contain either outright fradulent, or semi-fradulent information, including entity names, snail-mail addresses, phone numbers, and contact e-mail addresses. Although I do agree with Richard that this sort of thing is virtually unknown within APNIC, AFRINIC and LACNIC, ARIN whois records show even substantially more of this type of problem, in my experience, than do the RIPE whois records. (And note here that I'm not even counting cases in the ARIN space where clever companies, such as Tactara, have created legions of perfectly legal paper subsidiaries as a calculated way of thwarting accurate identification of the IP blocks that they themselves actually control.) Still, this is not to say that RIPE should in any way rest on its laurels, just because its whois records are, on average, somewhat less fradulent than those of one of its sister RiRs, and I would not counsel complacency. I don't think that there is any non-zero level of fraud that should be considered acceptable, in _any_ RiR. Regards, rfg

On Sep 29, 2010, at 5:54 PM, Richard Cox wrote:

Ronald F Guilmette <rfg@tristatelogic.com> wrote:

...

In my own experience, there do exist quite a substantial number of ARIN whois records which, as we speak, contain either outright fradulent, or semi-fradulent information, including entity names, snail-mail addresses, phone numbers, and contact e-mail addresses.

Sure. That's not what I was talking about. All RIRs have that problem to a greater or lesser degree. What seems to me to be unique to RIPE is the frequency of assignment of IP blocks/ASNs, to entities that fail to qualify for those resources under the relevant RIR's policies.

Can you please substantiate this claim? Thanks, Leo

On Sep 29, 2010, at 7:02 PM, Ronald F. Guilmette wrote: […]

I don't know about Richard, or anybody else, but I do think that _I_ could either confirm or refute the claim he made, *if* I could download the whole of the RIPE whois data base.

Can I? I mean is that allowed? If so, where do I sign up?

You can get the whole database except for contact information from the FTP site: ftp://ftp.ripe.net/ripe/dbase/split/ You can also get a realtime mirror, also excluding contact information. If you mail the RIPE NCC at ripe-dbm@ripe.net they can sign you up. Regards, Leo

On Sep 29, 2010, at 8:55 PM, Ronald F. Guilmette wrote:

In message <39E82643-D9E8-43A4-8E93-B04E021B9F88@icann.org>, Leo Vegoda <leo.vegoda@icann.org> wrote:

...

You can get the whole database except for contact information from the FTP site:

ftp://ftp.ripe.net/ripe/dbase/split/

Great! Thanks!

There are a whole lot of different files in there. Should I assume that the one I want is the Big One? (Well, anyway, that's what I fetching.)

It's one file per object type, so you only need to get the file for the objects you are interested in. The limerick and poetic-form objects don't have any Internet operational significance but are often amusing. Cheers, Leo

On Sep 29, 2010, at 7:45 PM, Richard Cox wrote:

Leo Vegoda <leo.vegoda@icann.org> wrote:

...

Can you please substantiate this claim?

I am certainly able to do that, but the totality of the data involved is substantial, and it would be more pragmatic to provide samples as needed. More data can be made available, depending on the purpose for which that substantiation is requested.

Evidence of several recent cases has already been sent to the RIPE Board via Nigel Titley. Nigel may or may not wish to comment on what action (if any) was taken as a result.

A statement from Nigel on a review of your data is more than adequate. Thanks, Leo

Richard, I have been following this thread now for a little while. As the person responsible for staff and actions of the RIPE NCC, I feel I have to comment shortly, before taking this particular issue offline for further discussion. On 30/09/2010 02:07, Richard Cox wrote:

I outlined at that meeting my concerns; there have certainly been actions of a discouraging nature by some NCC staff. I already gave you specific details within that meeting, and there is a broad convention that issues relating to actions of employees should not be discussed in public.

So all I am willing to say here is that the tone of feedback *from the NCC* was unhelpful, and issues raised at that meeting which one might reasonably expect to have been followed-up by the NCC since that meeting, have not been.

Indeed. You outlined your concerns, and we asked you to substantiate you claims, which you did not do. I can only offer again, that I am ready to follow up, if and when you solidify your claims. In the meantime, I reject any suggestions that RIPE NCC staff does not act neutrally and impartially, as they should according to our principles. And now please let us take this offline for resolution. cheers, Axel

Hello Richard,

The only decision-making part of a RIPE meeting such as is coming up in Rome in November, would be the RIPE Members' meeting. RIPE Members are limited to the LIRs, and not the likes of you or me.

That would be the RIPE NCC General Meeting, which is indeed limited to RIPE NCC members. RIPE != RIPE NCC. But this isn't relevant for this discussion because the decisions that are made at the GM usually are about board membership, the financial report and the charging scheme. Not about policy, which is made by the RIPE community, a.k.a. all of us. - Sander

In message <A.1P0wT9-0004Fy-9J@smtp-ext-layer.spamhaus.org>, Richard Cox <richard.cox@btuser.net> wrote:

Ronald F Guilmette <rfg@tristatelogic.com> wrote:

...

(Separate question: Is there any way to obtain archived dumps of the RIPE whois data base, e.g. from April of this year, so that I might be able to check and see if the original whois for the AS & IP block also said "Belize", as I suspect it did?)

Have you been introduced to the RIPE Resource Explainer yet? See: http://albatross.ripe.net/cgi-bin/rex.pl

No, I didn't know about that. Thanks for the tip!

It does not show the original WHOIS data (sadly) but it can be helpful.

Well, really, it was the older whois info (if any) for the AS and the IP block that I wanted to look at the most. Just a history of who has been routing a specific chunk of IP space is somewhat less interesting, from my perspective.

We can be reasonably sure that the resource holder for 195.80.148.0/22 is not in Belize because the phone numbers in the WHOIS record are in an invalid format for Belize. (See: http://wtng.info/wtng-501-bz.html) If they really were in Belize, they would know the local phone number format and so even if they wanted to submit fake phone numbers, they would probably get them in the correct format. Incidentally, we see that CIDR currently routing to Starnet, Moldova. No surprise there.

Is Starnet known to be... ah... dodgy?

But the BGP PATH downstream of Starnet (AS31252) is most unusual: "31252 12968 40975 41665 30968 50877" which tells us that packets are (allegedly) passing through routers announcing these networks:

AS31252 STARNET MOLDOVA AS12968 CROWLEY DATA POLAND AS40975 CHML WEB SERVICES ROMANIA AS41665 HOSTING.UA UKRAINE AS30968 INFOBOX.RU RUSSIA AS50877 INSTANTEXCHANGER "BELIZE"

But what may well be an ICMP filter at Starnet prevents traceroutes.

I think what we are seeing here is an ASN simulator, similar in concept to the traceroute simulators that have been used by the Russian Business Network. It is probably being used as part of a non-physical routing technology, such as BGP-VPN. If you go to route-views.routeviews.org, log in, and issue "sh ip bgp regex 12968" (without the quotes, natch!) Routeviews will show you all routes that have been contributed to Routeviews which allegedly pass through AS12968.

Thanks much for all this additional info Richard. I really didn't know any of this. I knew some other stuff that made that block look especially suspicious, but not any of the info that you just shared. I certainly hadn't made any sort of connection to RBN, however... It does certainly seem to me that _somebody_ may have taken serious umbrage to my recent attempts to call attention to various ASes and IP blocks that looked to me to be more than a little bit suspicious. Just a few short hours after I posted here about AS50877 and the 195.80.148.0/22 block, starting at around 06:16AM and continuing until around 06:51AM, local time (PDT, -0700) my firewall got lit up, continuously, like a veritable Christmas tree, with blocked TCP packets coming in to a wide variety of apparently random ports, from on the order of around 7 million different source IP addresses. (Yea, I know, spoofed.) Thankfully, I was asleep at the time, and thus was saved from a lot of needless worry and/or panic. No material damage seems to have been done, but I'm certainly glad that the last time I did an install, I allowed plenty of extra gigabytes for my /var/log partition, as I eneded up with some really obese log files.

... Now it is entirely possible for some Routeviews data to be misleading (not through any fault of Routeviews, but anyone who understands BGP will know what I'm referring to) and it's also possible for the above to happen for legitimate reasons, so other checks were needed to make certain that my results are meaningful: those checks have been done and they passed: I'm not going to post details for obvious reasons.

By "passed" I'm assuming that you mean that you've confirmed that 195.80.148.0/22 is rather on the dodgy side, yes?

...

Why would anyone bother to hijack an IP block or an ASN if RIPE will just issue you either of those things, willy nilly, no matter where you live?

The only advantages of hijacking a block in the RIPE service region are (a) that you would then avoid having to pay for it, and (b) that your conscience would be less likely to be troubled by the fact that some LIR had taken your money for submitting (probably) exaggerated information about your hardware etc to the RIPE NCC on your behalf.

So bringing this all back around to the issue of available WHOIS information, is there anything in the WHOIS for either AS50877 or 195.80.148.0/22 that a mere mortal such as myself could look at to determine which LIR had requested this specific IP block? Does Moldova have its own LIR? Is that the one that requested this block? Please tell me that _somebody_ is responsible here. Regards, rfg

In message <31623F62-318D-46E3-9ED9-50E98274AB19@st-kilda.org>, Fearghas McKay <fm-lists@st-kilda.org> wrote:

On 29 Sep 2010, at 23:42, Ronald F. Guilmette wrote:

...

Does Moldova have its own LIR? Is that the one that requested this = block?

Moldova doesn't have its own LIR - that doesn't mean that there are no = LIRs in Moldova.

Why do you assume a country would have an LIR ?

I didn't assume. I asked. I have now been educated to the contrary. Thank you. Regards, rfg