HI Ronald On 05/11/2015 21:33, Ronald F. Guilmette wrote:
In message <637758753.2826426.1446595528880.JavaMail.yahoo@mail.yahoo.com>, ripedenis@yahoo.co.uk wrote:
With regards to this specific incident (and this specific set of what looks to be 3 inter-related rogue ASNs) I myself don't really care which 1/5th of the world they are stealing IP space from. I just want to know who they really are. The region they are stealing from (at the moment) is almost irrelevant. By tomorrow, they'll be stealing from AFRINIC, and then from LACNIC the day afrer that.
This really does matter. Even with a valid RIPE ASN they cannot 'steal' RIPE address space. To create a ROUTE object for the RIPE address space the address space resource holder must validate the creation of the ROUTE object in the RIPE Database. So they can only 'steal' address space from other regions. This is allowed because there is no process in place to prevent these ROUTE objects being created in the RIPE Database at the moment. I have just sent a proposal to this mailing list to close this loop hole quickly. You may want to take a look at that.
I'm not even talking about (or even interested in) route objects in the data base at the moment. That's a whole different problem and a whole different kettle of fish. At the moment, I personally am focused on ORG- records.
As I have repeatedly said, it is my clear impression that the case of AS204224 *does not* involve anybody bribing anybody to create a new and/or largely fictitious company, but rather, this seem to be a good old-fashioned case of identity theft.
I may be wrong about that, but that also would be irrelevant.
I am certainly not so deluded as to believe that anything with either RIPE or RIPE NCC might do erase all traces of corruption from the face of the earth, and I am *not* urging that either RIPE or RIPE NCC set out on any quixotic quest to do so. Rather, I've suggested the much more modest goal of at least trying to insure that contact details present in the data base are actually associated with the parties they allegedly represent. Such a step would, I think, foil many, if not all attempts at identity theft, as in the case of AS204224, even through they quite certainly would have no effect at all on world-wide corruption.
... There should be no object in the database that is not directly or indirectly linked to an ORGANISATION object.
Again, we are in agreement. I'll even go further and say I am frankly rather surprised that the simple rule you just elaborated is not already in place.
There are a couple of points you need to understand here. First the data model is not organisation centric. The ORGANISATION object is not the key to representation in the database. The ORGANISATION object does not require any reference to any PERSON or ROLE object. So with a bogus company you will get your ORGANISATION object. When it comes to getting an ASN the AUT-NUM does require reference to a PERSON/ROLE object. But you can pick any PERSON or ROLE object in the database and reference them. Technically there is no cross checking. The 'owner' of those objects will not get notified. So unless the RIPE NCC questions your choice of objects all the contact data in those objects will be perfectly valid. They just have no relationship with you. cheers denis
Regards, rfg