[anti-abuse-wg] WHOIS (AS204224)

HI Ronald

On 05/11/2015 21:33, Ronald F. Guilmette wrote:
> In message <637758753.2826426.1446595528880.JavaMail.yahoo at mail.yahoo.com>,
> ripedenis at 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
>