[anti-abuse-wg] AS's with route objects for undelegated space

Richard,

Thanks for all of this. I had read the beginning of your earlier posts, 
but then got very distracted and was only reminded about them recently.

I have asked Registration Services in the NCC to look at this and 
hopefully some light may be able to be shed or progress made. We shall see.

Brian

On 05/11/2015 16:40, Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have read recent discussion here about AS204224 with interest...
>
> ... what seems to have escaped notice is rather temporary nature of the
> dubious route objects inserted into the RIPE database by AS204224.
>
> At the time of writing there are no such objects present, whereas at
> 03:45 this morning there were 5 such objects. That's a pattern that has
> continued for some time ...
>
> I noted the "now you see it, now you don't" behaviour a while back and
> have paid close attention for about a week.
>
> I speculate that, because a while ago I opened a ticket about AS204224,
> the RIPE NCC people are currently playing whack-a-mole in their own
> database system :( That is they are removing the route objects, and once
> they go home for the day AS204224 puts the objects back again!
>
> <https://www.lightbluetouchpaper.org/2015/11/02/ongoing-badness-in-the-
> ripe-database/>
>
> The alternative explanation is some sort of inherent shyness by the
> maintainers of AS204224 which causes them to remove their route objects
> when the sun rises ...
>
> It's been observed here that AS204224 is not alone, but I don't see a
> complete analysis... I think a full list of AS's which have a similar
> modus operandi (recently inserted route objects for undelegated space)
> would be (data is from 03:45 today, the count is of prefixes that are
> for un-delegated IPv4 address space):
>
>       AS21674, Recursos Numeracao Internet (24 prefixes, from July)
>
>       AS200439, LLC Stadis (4 prefixes, from Nov 4th)
>
>       AS200534, LLC Relax (5 prefixes, 4 from Nov 4th, 1 from June)
>
>       AS201432, RapidVDS (1 prefix from May)
>
>       AS204135, LLC Transmir (1 prefix from Nov 4th)
>
>       AS204210, CJSC TEPLOVODOMER (1 prefix from September)
>
>       AS204211, LLC Aspect (4 prefixed from early October)
>
>       AS204223, LLC Tehnokom (1 prefix from 4 Nov)
>
>       AS204224, CJSC Mashzavod-Marketing-Servis (5 prefixes from 4 Nov)
>
>       AS204225, OJSC Kommunenergo (1 prefix from September)
>
> If you don't see route objects when you look, then the "shyness" is
> clearly contagious.
>
> In addition to these AS's, there's now just under 50 other AS's who also
> have route objects for un-delegated space. This is IMHO undesirable, but
> they have been in this state for many years and I doubt that it fits
> with the dynamic and recent pattern for the prefixes above (indeed
> AS21674 looks like an outlier as well, I include it for being recent).
>
> I note the wish by some not to adopt a policing role, but it does seem
> to me that this is civic hygiene -- there is no legitimate reason I can
> see for the existence of a route object for un-routeable IPv4 space and
> that absent some sort of special circumstances appeal, I think it is
> entirely appropriate to treat the published records by the RIRs of the
> space that they have delegated as being authoritative.
>
> - --
> Dr Richard Clayton                               <richard.clayton at cl.cam.ac.uk>
> Director, Cambridge Cloud Cybercrime Centre          mobile: +44 (0)7887 794090
> Computer Laboratory, University of Cambridge, CB3 0FD   tel: +44 (0)1223 763570
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPsdk version 1.7.1
>
> iQA/AwUBVjuGgeINNVchEYfiEQLKZgCfRzKhmQdpaGsgnwaoKbFLlMf1ixMAmwUp
> nzhiUrbQw7jfimpH5TkFp78n
> =25Ns
> -----END PGP SIGNATURE-----
>