[db-wg] mntner with misleading primary key

Hello db-wg,

A simple query to the RIPEDB ('whois -h whois.ripe.net -r AS2856')
returns the aut-num AS2856 that you would expect, but it also returns a
mntner with the same primary key:


% Information related to 'as2856'

mntner:         as2856
admin-c:        JA6431-RIPE
auth:           SSO # Filtered
mnt-by:         as2856
created:        2018-08-23T15:46:37Z
last-modified:  2018-08-23T15:46:37Z
source:         RIPE # Filtered


This has caused some concern, and while we (2856) have already
determined how that mnter came to be in the database - and that there
isn't any immediate risk - it isn't in any way affiliated with the
AS2856 network, or any part of the parent company.

One can imagine that given the quality of NOCs & their understanding of
database objects the world over, that one of them might be convinced
that the person associated with this mntner was indeed associated with
the network AS2856, and they might also be convinced to announce
prefixes that they otherwise should not.

It is obvious that speaking to the owner of the mntner and politely
asking them to switch to a new mntner would be pertinent, but as far as
I'm aware they're under no obligation to do so. Yet, it feels that
AS2856 (or any network in the RIPE region) remains potentially at some
risk should a bad actor combine such a mntner, with some questionable
verification of their credentials, and socially engineer their way
toward a route hijack.

Should it be possible to create mntners (or other objects) that infer a
relationship and/or authority to a given aut-num (or organisation?)

Might there be negative side-effects in restricting the primary key of
mntners from impersonating other objects?

I'm unable to construct a query to the RIPEDB that looks for mntner
objects beginning with 'as', in order to gauge how common this is. I
suspect that's because the phrase is too short, but if it is possible
please do enlighten me! :)


Regards,

-- 
Tom