[dp-tf] Re: 91.198.71.0 - 91.198.71.255

Dear Richard,

Thank you for providing us with a list of specific resources that  
might be associated with this event. We will add them to our  
investigation. You can be sure that if we find fraudulent  
registrations, we will take appropriate action. Unfortunately neither  
the RIPE Policies nor our legal framework enables us to pursue action  
against any other type of abuse.

All requests that we receive are treated equally, and where needed, we  
verify the identity of the requester to the best of our abilities. We  
also monitor the RIPE Database for unauthorised changes and take  
action where required. Usually these cases turn out to be legitimate  
company name changes or changes of ownership. Some of the changes in  
the RIPE Database that you have noticed are such cases.

We do not however monitor the BGP routing table, as our mandate  
specifically does not extend to policing routing.

It has been suggested several times over the past years that we should  
police routing. However, there has never been consensus in the  
community that we should actually do this. If you wish to open a  
discussion on this issue, the Address Policy Working Group is probably  
the best venue.

A possible "land grab" for the remaining IPv4 address space is of  
course something that we keep a close watch on. So far, there have  
been no indications that one is ongoing. It is also highly unlikely  
that such a land grab would take the shape of a relatively small  
number of small PI assignments. The grand total of PI space that we  
assign is less than 2% of the total space that we assign and allocate,  
so such an event would be extremely noticeable. Also, as we publish  
our assignment and allocation data daily, there are more eyes than  
just ours watching, so a sudden change in these patterns would be very  
obvious to many people.

Resources that the RIPE NCC allocates and assigns are, in principle,  
for use in the RIPE region. Our policies do no define precisely what  
"use in the RIPE region" means. Over the years the RIRs have developed  
a procedural framework for dealing with cross-region requests:

- When the network is physically located in our region, even though  
connectivity might not go through our region, that network is eligible  
to receive resources from the RIPE NCC.
- When a network is physically located outside our region but the  
routing originates inside our region it is also eligible.
- When the request comes through a RIPE region LIR who is also the  
connectivity provider, it is also eligible.

Note that these are guidelines, as by their nature these requests  
cover a large variety of situations. When needed, there is  
communication between the different RIRs about such requests.

If you have noticed a disparity between the different RIRs that does  
not come from differences in the regional policies, I would be very  
interested to hear about this.

I have also discussed your request for historical data with our legal  
team, and any data not currently available to the public requires a  
court order for the RIPE NCC to release it. This applies even to data  
that was published in the past, but is no longer publicly available.

Finally, your suggestion to include the identity of the LIR in PI/AS  
assignment objects is an interesting one. If you wish to pursue it, it  
should be made to the Database and/or Address Policy Working Groups.

Best Regards,

Alex Le Heux
RIPE NCC
On Nov 4, 2007, at 17:50, Richard Cox wrote:

> (Copied to APWG-Chairs and DP-TF in view of the policy implications)
>
> On 02/11/2007 16:36:35, Alex Le Heux <alexlh at ripe.net> wrote:
>
>> As it turns out, we had already noticed the change in registration
>> data a few weeks ago and are currently in contact with the LIR.
>> We have established procedures that are designed to track changes
>> like this, and this case is already under investigation.
>
> There appear to be seven other ranges and ASNs, similarly acquired.
>
> 	193.33.128.0/23  AS42672	194.110.69.0/24  AS42811
> 	91.193.40.0/22   AS42662	91.193.56.0/22   AS42672
> 	91.194.140.0/23  AS43188	91.195.116.0/23  AS43702
> 	91.196.232.0/22  AS43259	91.198.71.0/24   AS43603
>
>> We have audited the request and our policies and procedures
>> were correctly applied when this range was assigned.
>
> That's obviously very worrying - because it implies that any similar
> new application now would also be granted, and the claims that RIPE
> still has three years to go before IP4 exhaustion would then be seen
> as having been highly optimistic!
>
> I note your earlier comment about the data having been recently  
> changed:
> so are you saying that the original application was valid just because
> it had an address in the RIPE region - even though that address may  
> have
> been meaningless?  If so, are you able to remind us what that address
> originally was (as at the time it would have been "public" data)?
>
> As you may know, the entity believed to be using these IP  
> assignments is
> the notorious "Russian Business Network" about which much has recently
> been written: and http://en.wikipedia.org/wiki/ 
> Russian_Business_Network
> provides a convenient index to the more significant of those articles.
>
> The RIPE NCC cannot, of course, be concerned with any criminal  
> activity
> that uses IP addresses it assigns, but I believe the RIPE NCC does  
> need
> to be concerned about the obtaining by dishonest means of resources  
> that
> are owned by the community and entrusted to the stewardship of RIPE  
> NCC.
>
> During RIPE 55 I mentioned the earlier cases of shell companies set up
> apparently by a "Boris Mizhen" to apply for IP resources for spamming
> purposes (ie to avoid filters) and I understand that the LIR handling
> those applications (Merezha) has previously been linked to  
> questionable
> assignments.  For the record, the IP ranges and ASNs involved with  
> that
> series of incidents, were as follows:
>
> 	91.193.152.0/22  AS42719	91.193.192.0/22  AS42719
> 	91.193.216.0/22  AS42719	91.193.88.0/22   AS42719
> 	91.200.124.0/22  AS42719	91.200.132.0/22  AS42719
> 	91.200.164.0/22  AS42719	91.200.176.0/22  AS42719
> 	91.200.56.0/22   AS43791	91.200.60.0/22   AS43791
> 	91.200.72.0/22   AS43799	91.200.80.0/22   AS43799
>
> I (and others) mentioned at the Address Policy WG the probability of  
> an
> imminent IPv4 landgrab - these two recent incidents seem to suggest  
> that
> it has started.  How well can RIPE policies stand up to such  
> deliberate
> and abusive attacks?  In particular, how protected would the community
> be against an LIR that intentionally submits applications which rely  
> on
> data the LIR knows is bogus?  The LIR is not identified on the WHOIS
> output - but if the only policing of the application is done by the  
> LIRs
> (as I'm told that RIPE hostmasters are not allowed to question details
> supporting an application for resources) perhaps the identity of the  
> LIR
> should be displayed against the IP range, so that patterns of  
> dishonesty
> can quickly become visible?
>
>> We do sometimes assign resources to organisations for use outside our
>> region, although it rarely happens, and such requests are handled  
>> very
>> carefully as they are rather unusual.
>
> I'd welcome some clarification on the policies involved there: is that
> just to entities ("organisations") located, at least nominally, within
> the RIPE service region: with operations outside that region - or  
> would
> entities/organisations within other regions qualify?  I ask because  
> the
> other questionable incident that came to our attention recently was  
> the
> use of 85.255.112.0/20 in California USA, when it was shown in the  
> RIPE
> database as unassigned space: and we discovered that an assignment  
> was,
> mysteriously, made of that space by the RIPE Hostmaster to  
> "Inhoster" on
> the very day I pointed out the inappropriate use, and that assignment
> has also recently had its data changed: showing it as now being  
> assigned
> to a "UkrTeleGroup".  But still it is used - solely - in California  
> USA.
>
>> It is a normal occurrence that a request is denied by one of the  
>> RIRs.
>> If the reason for the denial is related to the location of the  
>> network,
>> the end-user is then referred to the correct RIR.  This is normally
>> nothing to be suspicious about as there are many legitimate
>> organisations that have operations in multiple RIR regions.
>
> Given the (apparent) disparity in policy implementation between RIPE
> and the other RIRs - most of whose hostmasters are empowered to (and
> indeed do) check for and reject abusive applications it seems RIPE
> may soon be regularly targeted by organisations worldwide who cannot,
> for whatever reason, get resource assignments from their local RIR.
>
>> Could you tell us a little about the circumstances that brought
>> this range to your attention? Any information might help us with
>> our investigation.
>
> We have been tracking the "Russian Business Network" and also "Boris
> Mizhen" for some time now, and we have been monitoring routing and
> other changes which tell us their traffic has moved to new routes.
> It is, however, unlikely that their actual location has changed, as
> traceroutes to IP addresses in the new ranges are indicative of the
> use of a "traceroute simulator" rather than of a real network path.
>
> Best regards
>
> -- 
>   Richard D G Cox <cio at spamhaus.org>
>   CIO, The Spamhaus Project
>   http://www.spamhaus.org
>

Best regards,

Alex Le Heux
RIPE NCC IP Resource Analyst