AS's with route objects for undelegated space
-----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@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-----
Hi Richard On 05/11/2015 17: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.
This really is so easy to fix but no one is interested in a quick fix :( cheers denis
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@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-----
In message <NOVQluCBa4OWFAj2@highwayman.com>, Richard Clayton <richard@highwayman.com> wrote:
I note the wish by some not to adopt a policing role, but it does seem to me that this is civic hygiene...
I await the inevitable... "We are not the civic hygienists!" :-) Regards, rfg P.S. Thanks for your report about those other ASNs. Facinating.
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@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-----
participants (4)
-
Brian Nisbet -
denis -
Richard Clayton -
Ronald F. Guilmette