[anti-abuse-wg] WHOIS (AS204224)

Hi Ronald,

> Op 2 nov. 2015, om 07:38 heeft Ronald F. Guilmette <rfg at tristatelogic.com> het volgende geschreven:
> 
> The claim clearly being asserted by the RIPE WHOIS record for AS204224
> is that this is an *IN-REGION* (Russian) company, one which, as I noted,
> is apparently a 16 year old parts & equipment supplier for the oil & gas
> industry, that suddenly, and for no apparently clear reason, this past
> summer, after 16 years in business, decided that it needed its own
> RIPE-sponsored AS

Apparently. Although in this case you may be right in that it is a fake registration (I have no idea and I don't have the resources to verify) there are plenty of companies that need their own AS for i.e. multi-homing. Even if they are 16 years old, they may have changed their business model etc.

How do you propose to distinguish people/companies with bad intentions (for some value of bad, let's assume "planning to send spam") from normal companies? It is certainly not self-evident. Our community and service region is much too diverse for that.

> , got one, and then proceeded to announce a bunch of
> self-evidently bogus routes to relatively large swaths of APNIC address
> space.

"Self-evidently" is a lousy argument. The routes may be bogus in this case, but how do you propose to distinguish bogus routes from merely unusual routes?

> The issue isn't the announcement of out-of-region IP space.  The issue
> is the self-evidently fradulent nature of the registration of, and the
> WHOIS record for, AS204224.

Again that lousy "self-evidently" argument. Please don't use that, it is often used by people who don't have any better arguments and want to fool the casual reader into agreeing with them without thinking. Real data please.

> That AS, as I pointed out, was registered within 7 minutes of yet
> another highly dubious AS (i.e. AS204223)

RIPE NCC has assigned 2044 ASNs so far this year (based on delegated-ripencc-latest). It isn't that strange that two ASNs get registered within 7 minutes of each other. Especially not of they both have the same sponsoring LIR, where an employee might just have saved all requests to RIPE NCC to process them all at once for efficiency.

When you see later that multiple ASNs have been used to send spam it is not difficult to find some similarities between them. But that doesn't mean that all ASN requests which show some similarities are suspicious by default.

Again: what exactly do you propose to do with this data? How does this help us make better policies?

> , which also, perhaps not
> conincidently, has itself recently also been caught red-handed,
> also announcing several similarly sized bogons from the exact same
> geographical region as the bogons that AS204224 has been announcing.

Hindsight is always nice, but this doesn't help us in trying to prevent abuse.

> Oh!  And let's not forget what started this, i.e. the fact that
> AS204223 is itself upstream from yet a third dubious AS, and one which
> Furio Ercolessi reported here as ALSO announcing a number of bogons,
> AND ACTIVELY SPAMMING FROM THOSE.

Again: hindsight is nice.

> You apparently think that all of this is mere coincidence.

Doesn't sound like it the way you put it, but you haven't shown anything yet that isn't based on hindsight and speculation...

>>> From where I am sitting however it appears me that the both the
>>> data contained in the RIPE WHOIS record for AS204224 and also
>>> whatever process RIPE NCC followed to validate that data are...
>>> not to put too fine a point on it... nothing short of bovine
>>> excrement.
>> 
>> Evidence please, until then I will regard this as baseless
>> slander. 
> 
> So, you are of the opinion that the WHOIS data for AS204224 is all
> perfectly fine and dandy, yes?  You don't find anything at all in
> the least bit suspicious about a 16 year old Russian oil & gas parts
> supplier suddenly coming out of the woodwork, suddenly needing their
> own AS number

Not at all. As I said: these things happen. Businesses change, evolve. And at some point they may need their own ASN.

> , and, as their very first act upon acquiring their
> shiny new AS number, announcing a bunch of bogons to IP space they
> have no rights to

How do you know that they don't have the right to announce those addresses? Is it unallocated space? In that case it's easy. Is it space allocated to someone else? In that case there is no way you can say that they have no right without contacting the legitimate holder.

> , exactly like ANOTHER different AS number is doing,
> a different AS that just happens to have been created only 7 minutes
> earlier?

Maybe suspicious with hindsight. Nothing that RIPE NCC could/should have acted on when the request was made.

> I want to be clear here.  Is that really what you are saying?
> I'd like to get your answer on the record... for posterity.

Here you have mine :)

>>> Forget ICANN.  Is _RIPE_ also a slacker when it comes to
>>> maintaining its own WHOIS data base?  Are officially sanctioned
>>> RIPE policies and procedures making to harder than it ought to
>>> be to stop, or even to just merely identify criminals, con men,
>>> and spammers on the Internet?  If so, when was that decision
>>> ratified, and by whom?
>> 
>> The Policy Development Process is detailed in documentation on
>> the abovementioned website.
> 
> [...]
> 
> My question was:  When was the DECISION made not to bother to verify
> the phone numbers and mailing addresses that go into the RIPE WHOIS
> data base?  And also: Who made that specific DECISION?

The current rules for assigning ASNs are here:
https://www.ripe.net/publications/docs/ripe-638

This policy refers to this policy on contractual requirements:
https://www.ripe.net/publications/docs/ripe-637

Which includes:
"the LIR is responsible for liaising with the resource holder to keep registration records up-to-date"

"the resource holder is obliged to provide up-to-date registration data to the LIR and that some or all of this registration data will be published in the RIPE WHOIS Database"

Their content has been decided by the RIPE Address Policy Working Group.

> (I understand that I may have failed to be adequately clear earlier,
> but I wanted to be clear now that my question was not about the
> "Policy Development Process".  I thank you however for you kind
> attempts to educate me about this largely unrelated topic.

It's not unrelated, it's how DECISIONS are made.

> I'm
> interested in the moment in THE DECISION, not in official pronouncements
> regarding the idealized notion of the political process that may or
> may not have been followed leading up to THE DECISION.)

The RIPE Address Policy Working groups are where THE DECISIONS are made. It uses the Policy Development Process to reach those DECISIONS in an open and transparent way. If you don't care about the process: fine. But if you want to change policies then that's how you do it.

> Or were you trying, in a back-handed sort of way, to tell me that
> the verification of phone and address parts of RIPE WHOIS records
> isn't being done because it wasn't even ever considered as being either
> necessary or useful enough to even insert the idea into the front
> end of the meat grinder known as "The Policy Development Process" ?

Policy usually doesn't contain details like that explicitly. It defines that registration data has to be up-to-date, and the implementation is done by RIPE NCC. The policy says that there has to be either an indirect or a direct contractual link between the End User and RIPE NCC. For the ASNs you mentioned the link goes from RIPE NCC to a sponsoring LIR to the end user.

Contract between RIPE NCC and LIRs is published here:
https://www.ripe.net/publications/docs/ripe-626

9.4f entitles the RIPE NCC to terminate the contract "if the Member provides the RIPE NCC with falsified or misleading data or provides the RIPE NCC repeatedly with incorrect data"

The exact contents of the contract between the LIR and the end user are not public, but it must contain things like keeping data up-to-date (see ripe-637 above).

> If THAT was really what you were trying to say, then you'll have to
> excuse me while I pick my jaw up off the floor.

The policies contain requirements for up-to-date data, and the RIPE NCC service contract does contain language against falsified, misleading and incorrect data.

The big problem has always been: how do you verify that data? Many things you labelled as "self-evident" are certainly not, especially not up front. The RIPE NCC covers a huge service region with many different jurisdictions. Some are politically unstable (this might be an understatement) like Syria and Ukraine. How do you propose an association based in The Netherlands like the RIPE NCC consistently verifies business records, phone numbers and addresses in such a variety of countries and jurisdictions?

Complaining that "things should be better" is easy. But the RIPE NCC isn't a government entity or a business. It's an association of people and organisations. And the policies it implements are those decided on by the wider RIPE internet community, which is open to all. If things need to improve it is there that the work needs to be done. I have asked you a number of questions, and I think those are the questions that need to be though about and answered if you want to make things better. Those answers can then lead to a policy. This policy must be neutral, unambiguous, implementable, verifiable etc. and not be based on circumstantial "evidence", "self-evident" data and hindsight. This is not easy.

Cheers,
Sander

PS: And then you should also remember that not all resources are allocated or assigned to businesses. A private person can also hold address space and ASNs (popular amongst network engineers, but also for e.g. small associations and other groups). There needs to be a balance between public records and privacy there.