An arrest in Russia
![](https://secure.gravatar.com/avatar/daa9ea618351eb68baad89b6dfab4f28.jpg?s=120&d=mm&r=g)
Anyone have more details about this? https://belsat.eu/en/news/runet-founder-under-house-arrest/ The Czech company that allagedly received the allegedly stolen 7.5 "B" blocks (/16) would seem to be this one: ORG-RCS23-RIPE AS15731 https://www.ripe.net/membership/indices/data/cz.relcom.html But I am not seeing that ORG as having quite that many IPv4 addresses assigned. Maybe the alleged perp in this case only stole IPv6 addresses (?) Regards, rfg
![](https://secure.gravatar.com/avatar/296c2094b1de39ba00ea926c061d4fda.jpg?s=120&d=mm&r=g)
Peace, No, IPv6 is outta question here. The particular details are still unclear to me — and pretty much everyone else both in Prague and Moscow. Can keep the list posted if you want. -- Töma On Sat, Dec 28, 2019, 1:35 AM Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
Anyone have more details about this?
https://belsat.eu/en/news/runet-founder-under-house-arrest/
The Czech company that allagedly received the allegedly stolen 7.5 "B" blocks (/16) would seem to be this one:
ORG-RCS23-RIPE AS15731
https://www.ripe.net/membership/indices/data/cz.relcom.html
But I am not seeing that ORG as having quite that many IPv4 addresses assigned.
Maybe the alleged perp in this case only stole IPv6 addresses (?)
Regards, rfg
![](https://secure.gravatar.com/avatar/c512c2e8c622bd1a40f006d8008898c0.jpg?s=120&d=mm&r=g)
On Fri, Dec 27, 2019 at 02:35:29PM -0800, Ronald F. Guilmette wrote:
Anyone have more details about this?
https://belsat.eu/en/news/runet-founder-under-house-arrest/
The Czech company that allagedly received the allegedly stolen 7.5 "B" blocks (/16) would seem to be this one:
ORG-RCS23-RIPE AS15731
https://www.ripe.net/membership/indices/data/cz.relcom.html
But I am not seeing that ORG as having quite that many IPv4 addresses assigned.
Maybe the alleged perp in this case only stole IPv6 addresses (?)
Hello Ron, in https://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt under cz.relcom you can currently see the equivalent of about 2.6 "B" blocks. However, only 10 days they were apparently a lot more! For instance, the list at https://www-public.imtbs-tsp.eu/~maigron/RIR_Stats/RIPE_Allocations/Allocs/C... was collected on Thu Dec 19 2019 and shows the equivalent of about 9.6 "B" blocks (I enclose it below). So the majority of those blocks appears to have changed LIR, leaving cz.relcom/AS2118-MNT to return to ROSNIIROS (aka RIPN) in the past 10 days. Example: inetnum: 193.232.0.0 - 193.232.63.255 netname: RU-ROSNIIROS-19930609 country: RU org: ORG-RRIf1-RIPE admin-c: RR-ORG tech-c: RR-ORG status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-by: ROSNIIROS-MNT mnt-lower: ROSNIIROS-MNT mnt-routes: AS3316-MNT mnt-routes: ROSNIIROS-MNT created: 2019-12-24T10:32:16Z <============== last-modified: 2019-12-24T10:32:16Z <============== source: RIPE furio ercolessi ================================================================================= Data from RIPE NCC website as of: Thu Dec 19 2019 cz.relcom Reliable Communications s.r.o. 19930609 193.232.0.0/18 ALLOCATED PA 19930609 193.232.65.0/24 ALLOCATED PA 19930609 193.232.68.0/23 ALLOCATED PA 19930609 193.232.70.0/24 ALLOCATED PA 19930609 193.232.75.0/24 ALLOCATED PA 19930609 193.232.77.0/24 ALLOCATED PA 19930609 193.232.79.0/24 ALLOCATED PA 19930609 193.232.86.0/24 ALLOCATED PA 19930609 193.232.88.0/22 ALLOCATED PA 19930609 193.232.92.0/24 ALLOCATED PA 19930609 193.232.95.0/24 ALLOCATED PA 19930609 193.232.96.0/20 ALLOCATED PA 19930609 193.232.112.0/21 ALLOCATED PA 19930609 193.232.120.0/22 ALLOCATED PA 19930609 193.232.130.0/24 ALLOCATED PA 19930609 193.232.138.0/24 ALLOCATED PA 19930609 193.232.144.0/21 ALLOCATED PA 19930609 193.232.152.0/22 ALLOCATED PA 19930609 193.232.158.0/23 ALLOCATED PA 19930609 193.232.160.0/21 ALLOCATED PA 19930609 193.232.168.0/22 ALLOCATED PA 19930609 193.232.172.0/23 ALLOCATED PA 19930609 193.232.174.0/24 ALLOCATED PA 19930609 193.232.176.0/22 ALLOCATED PA 19930609 193.232.180.0/24 ALLOCATED PA 19930609 193.232.182.0/23 ALLOCATED PA 19930609 193.232.184.0/22 ALLOCATED PA 19930609 193.232.192.0/19 ALLOCATED PA 19930609 193.232.224.0/23 ALLOCATED PA 19930609 193.232.228.0/23 ALLOCATED PA 19930609 193.232.234.0/23 ALLOCATED PA 19930609 193.232.236.0/24 ALLOCATED PA 19930609 193.232.238.0/23 ALLOCATED PA 19930609 193.232.240.0/23 ALLOCATED PA 19930609 193.232.242.0/24 ALLOCATED PA 19930609 193.232.245.0/24 ALLOCATED PA 19930609 193.232.246.0/23 ALLOCATED PA 19930609 193.232.248.0/21 ALLOCATED PA 19930901 193.124.0.0/24 ALLOCATED PA 19930901 193.124.2.0/23 ALLOCATED PA 19930901 193.124.4.0/22 ALLOCATED PA 19930901 193.124.8.0/23 ALLOCATED PA 19930901 193.124.15.0/24 ALLOCATED PA 19930901 193.124.16.0/22 ALLOCATED PA 19930901 193.124.22.0/23 ALLOCATED PA 19930901 193.124.24.0/24 ALLOCATED PA 19930901 193.124.30.0/24 ALLOCATED PA 19930901 193.124.33.0/24 ALLOCATED PA 19930901 193.124.34.0/23 ALLOCATED PA 19930901 193.124.36.0/24 ALLOCATED PA 19930901 193.124.40.0/23 ALLOCATED PA 19930901 193.124.42.0/24 ALLOCATED PA 19930901 193.124.44.0/22 ALLOCATED PA 19930901 193.124.49.0/24 ALLOCATED PA 19930901 193.124.50.0/24 ALLOCATED PA 19930901 193.124.55.0/24 ALLOCATED PA 19930901 193.124.56.0/22 ALLOCATED PA 19930901 193.124.60.0/24 ALLOCATED PA 19930901 193.124.64.0/22 ALLOCATED PA 19930901 193.124.80.0/24 ALLOCATED PA 19930901 193.124.88.0/21 ALLOCATED PA 19930901 193.124.112.0/22 ALLOCATED PA 19930901 193.124.117.0/24 ALLOCATED PA 19930901 193.124.118.0/23 ALLOCATED PA 19930901 193.124.121.0/24 ALLOCATED PA 19930901 193.124.124.0/23 ALLOCATED PA 19930901 193.124.128.0/22 ALLOCATED PA 19930901 193.124.133.0/24 ALLOCATED PA 19930901 193.124.158.0/23 ALLOCATED PA 19930901 193.124.200.0/21 ALLOCATED PA 19930901 193.124.224.0/22 ALLOCATED PA 19930901 193.124.254.0/24 ALLOCATED PA 19940613 194.58.31.0/24 ALLOCATED PA 19940613 194.58.32.0/23 ALLOCATED PA 19940613 194.58.34.0/24 ALLOCATED PA 19940613 194.58.36.0/22 ALLOCATED PA 19940613 194.58.40.0/21 ALLOCATED PA 19940613 194.58.56.0/22 ALLOCATED PA 19940613 194.58.60.0/23 ALLOCATED PA 19940613 194.58.66.0/23 ALLOCATED PA 19940613 194.58.68.0/22 ALLOCATED PA 19940613 194.58.82.0/23 ALLOCATED PA 19940613 194.58.154.0/23 ALLOCATED PA 19940613 194.58.222.0/23 ALLOCATED PA 19940613 194.58.241.0/24 ALLOCATED PA 19940613 194.58.246.0/24 ALLOCATED PA 19940819 194.85.1.0/24 ALLOCATED PA 19940819 194.85.2.0/24 ALLOCATED PA 19940819 194.85.4.0/22 ALLOCATED PA 19940819 194.85.8.0/22 ALLOCATED PA 19940819 194.85.14.0/23 ALLOCATED PA 19940819 194.85.17.0/24 ALLOCATED PA 19940819 194.85.18.0/23 ALLOCATED PA 19940819 194.85.20.0/22 ALLOCATED PA 19940819 194.85.24.0/24 ALLOCATED PA 19940819 194.85.26.0/23 ALLOCATED PA 19940819 194.85.30.0/24 ALLOCATED PA 19940819 194.85.48.0/20 ALLOCATED PA 19940819 194.85.64.0/21 ALLOCATED PA 19940819 194.85.80.0/22 ALLOCATED PA 19940819 194.85.86.0/23 ALLOCATED PA 19940819 194.85.88.0/21 ALLOCATED PA 19940819 194.85.96.0/22 ALLOCATED PA 19940819 194.85.102.0/23 ALLOCATED PA 19940819 194.85.110.0/23 ALLOCATED PA 19940819 194.85.112.0/22 ALLOCATED PA 19940819 194.85.116.0/24 ALLOCATED PA 19940819 194.85.120.0/21 ALLOCATED PA 19940819 194.85.128.0/19 ALLOCATED PA 19940819 194.85.178.0/23 ALLOCATED PA 19940819 194.85.180.0/22 ALLOCATED PA 19940819 194.85.184.0/24 ALLOCATED PA 19940819 194.85.188.0/24 ALLOCATED PA 19940819 194.85.192.0/19 ALLOCATED PA 19940819 194.85.224.0/20 ALLOCATED PA 19940819 194.85.248.0/22 ALLOCATED PA 19940819 194.85.254.0/23 ALLOCATED PA 19940901 194.87.0.0/17 ALLOCATED PA 19940901 194.87.128.0/17 ALLOCATED PA 19950206 194.135.1.0/24 ALLOCATED PA 19950206 194.135.2.0/24 ALLOCATED PA 19950206 194.135.16.0/23 ALLOCATED PA 19950206 194.135.18.0/24 ALLOCATED PA 19950206 194.135.20.0/24 ALLOCATED PA 19950206 194.135.22.0/23 ALLOCATED PA 19950206 194.135.24.0/23 ALLOCATED PA 19950206 194.135.30.0/24 ALLOCATED PA 19950206 194.135.32.0/21 ALLOCATED PA 19950206 194.135.44.0/23 ALLOCATED PA 19950206 194.135.46.0/24 ALLOCATED PA 19950206 194.135.104.0/23 ALLOCATED PA 19950206 194.135.119.0/24 ALLOCATED PA 19950206 194.135.124.0/24 ALLOCATED PA 19950807 194.190.0.0/18 ALLOCATED PA 19950807 194.190.64.0/19 ALLOCATED PA 19950807 194.190.96.0/20 ALLOCATED PA 19950807 194.190.112.0/22 ALLOCATED PA 19950807 194.190.116.0/23 ALLOCATED PA 19950807 194.190.118.0/24 ALLOCATED PA 19950807 194.190.130.0/23 ALLOCATED PA 19950807 194.190.137.0/24 ALLOCATED PA 19950807 194.190.139.0/24 ALLOCATED PA 19950807 194.190.140.0/24 ALLOCATED PA 19950807 194.190.143.0/24 ALLOCATED PA 19950807 194.190.144.0/24 ALLOCATED PA 19950807 194.190.147.0/24 ALLOCATED PA 19950807 194.190.149.0/24 ALLOCATED PA 19950807 194.190.150.0/23 ALLOCATED PA 19950807 194.190.152.0/23 ALLOCATED PA 19950807 194.190.154.0/24 ALLOCATED PA 19950807 194.190.157.0/24 ALLOCATED PA 19950807 194.190.158.0/23 ALLOCATED PA 19950807 194.190.160.0/21 ALLOCATED PA 19950807 194.190.169.0/24 ALLOCATED PA 19950807 194.190.170.0/23 ALLOCATED PA 19950807 194.190.172.0/22 ALLOCATED PA 19950807 194.190.176.0/20 ALLOCATED PA 19950807 194.190.192.0/19 ALLOCATED PA 19960103 194.226.0.0/20 ALLOCATED PA 19960103 194.226.19.0/24 ALLOCATED PA 19960103 194.226.20.0/22 ALLOCATED PA 19960103 194.226.26.0/23 ALLOCATED PA 19960103 194.226.30.0/23 ALLOCATED PA 19960103 194.226.32.0/22 ALLOCATED PA 19960103 194.226.37.0/24 ALLOCATED PA 19960103 194.226.40.0/24 ALLOCATED PA 19960103 194.226.42.0/23 ALLOCATED PA 19960103 194.226.45.0/24 ALLOCATED PA 19960103 194.226.49.0/24 ALLOCATED PA 19960103 194.226.50.0/23 ALLOCATED PA 19960103 194.226.52.0/22 ALLOCATED PA 19960103 194.226.60.0/22 ALLOCATED PA 19960103 194.226.96.0/24 ALLOCATED PA 19960103 194.226.98.0/23 ALLOCATED PA 19960103 194.226.104.0/21 ALLOCATED PA 19960103 194.226.112.0/22 ALLOCATED PA 19960103 194.226.120.0/22 ALLOCATED PA 19960103 194.226.124.0/23 ALLOCATED PA 19960103 194.226.126.0/24 ALLOCATED PA 19960103 194.226.128.0/22 ALLOCATED PA 19960103 194.226.132.0/23 ALLOCATED PA 19960103 194.226.136.0/22 ALLOCATED PA 19960103 194.226.142.0/23 ALLOCATED PA 19960103 194.226.144.0/20 ALLOCATED PA 19960103 194.226.160.0/19 ALLOCATED PA 19960103 194.226.224.0/19 ALLOCATED PA 19960419 195.208.0.0/20 ALLOCATED PA 19960419 195.208.16.0/22 ALLOCATED PA 19960419 195.208.20.0/23 ALLOCATED PA 19960419 195.208.32.0/19 ALLOCATED PA 19960419 195.208.64.0/18 ALLOCATED PA 19960419 195.208.128.0/18 ALLOCATED PA 19960419 195.208.192.0/20 ALLOCATED PA 19960419 195.208.216.0/22 ALLOCATED PA 19960419 195.208.220.0/23 ALLOCATED PA 19960719 195.209.64.0/18 ALLOCATED PA 19960719 195.209.128.0/21 ALLOCATED PA 19960719 195.209.136.0/24 ALLOCATED PA 19960719 195.209.138.0/23 ALLOCATED PA 19960719 195.209.140.0/22 ALLOCATED PA 19960719 195.209.144.0/23 ALLOCATED PA 19960719 195.209.149.0/24 ALLOCATED PA 19960719 195.209.150.0/23 ALLOCATED PA 19960719 195.209.160.0/19 ALLOCATED PA 19960719 195.209.192.0/19 ALLOCATED PA 19961029 195.19.0.0/21 ALLOCATED PA 19961029 195.19.9.0/24 ALLOCATED PA 19961029 195.19.10.0/23 ALLOCATED PA 19961029 195.19.12.0/23 ALLOCATED PA 19961029 195.19.16.0/21 ALLOCATED PA 19961029 195.19.24.0/23 ALLOCATED PA 19961029 195.19.27.0/24 ALLOCATED PA 19961029 195.19.28.0/22 ALLOCATED PA 19961029 195.19.32.0/19 ALLOCATED PA 19961029 195.19.64.0/18 ALLOCATED PA 19970409 195.19.128.0/17 ALLOCATED PA 19970415 195.133.0.0/18 ALLOCATED PA 19970415 195.133.64.0/19 ALLOCATED PA 19970415 195.133.192.0/21 ALLOCATED PA 19970415 195.133.200.0/23 ALLOCATED PA 19970616 62.76.0.0/20 ALLOCATED PA 19970616 62.76.16.0/21 ALLOCATED PA 19970616 62.76.28.0/22 ALLOCATED PA 19970616 62.76.32.0/20 ALLOCATED PA 19970616 62.76.64.0/21 ALLOCATED PA 19970616 62.76.72.0/22 ALLOCATED PA 19970616 62.76.78.0/23 ALLOCATED PA 19970616 62.76.80.0/21 ALLOCATED PA 19970616 62.76.92.0/22 ALLOCATED PA 19970616 62.76.96.0/22 ALLOCATED PA 19970616 62.76.104.0/21 ALLOCATED PA 19970616 62.76.116.0/22 ALLOCATED PA 19970616 62.76.120.0/24 ALLOCATED PA 19970616 62.76.122.0/23 ALLOCATED PA 19970616 62.76.124.0/22 ALLOCATED PA 19970616 62.76.128.0/20 ALLOCATED PA 19970616 62.76.144.0/22 ALLOCATED PA 19970616 62.76.148.0/23 ALLOCATED PA 19970616 62.76.150.0/24 ALLOCATED PA 19970616 62.76.152.0/21 ALLOCATED PA 19970616 62.76.160.0/19 ALLOCATED PA 19970616 62.76.192.0/19 ALLOCATED PA 19970616 62.76.224.0/20 ALLOCATED PA 19970616 62.76.246.0/23 ALLOCATED PA 19970630 195.58.32.0/19 ALLOCATED PA 19980115 212.192.0.0/19 ALLOCATED PA 19980115 212.192.32.0/19 ALLOCATED PA 19980115 212.192.64.0/19 ALLOCATED PA 19980115 212.192.112.0/20 ALLOCATED PA 19980115 212.192.128.0/19 ALLOCATED PA 19980115 212.192.168.0/23 ALLOCATED PA 19980115 212.192.192.0/20 ALLOCATED PA 19980115 212.192.208.0/20 ALLOCATED PA 19980115 212.192.224.0/22 ALLOCATED PA 19980115 212.192.228.0/23 ALLOCATED PA 19980115 212.192.240.0/20 ALLOCATED PA 19990512 212.193.0.0/19 ALLOCATED PA 19990512 212.193.32.0/19 ALLOCATED PA 19990512 212.193.64.0/19 ALLOCATED PA 19990512 212.193.96.0/21 ALLOCATED PA 19990512 212.193.128.0/20 ALLOCATED PA 19990512 212.193.160.0/19 ALLOCATED PA 19990512 212.193.224.0/19 ALLOCATED PA 20180504 193.108.112.0/22 ALLOCATED PA 20100304 2a00:1c88::/32 20120605 2a01:57c0::/32 20141001 2a03:3ae0::/32
![](https://secure.gravatar.com/avatar/daa9ea618351eb68baad89b6dfab4f28.jpg?s=120&d=mm&r=g)
In message <20191228020627.GA9820@allog.giato>, furio ercolessi <furio+as@spin.it> wrote:
On Fri, Dec 27, 2019 at 02:35:29PM -0800, Ronald F. Guilmette wrote:
Anyone have more details about this?
https://belsat.eu/en/news/runet-founder-under-house-arrest/
The Czech company that allagedly received the allegedly stolen 7.5 "B" blocks (/16) would seem to be this one:
ORG-RCS23-RIPE AS15731
https://www.ripe.net/membership/indices/data/cz.relcom.html
But I am not seeing that ORG as having quite that many IPv4 addresses assigned.
Maybe the alleged perp in this case only stole IPv6 addresses (?)
Hello Ron,
in https://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt under cz.relcom you can currently see the equivalent of about 2.6 "B" blocks.
However, only 10 days they were apparently a lot more! For instance, the list at https://www-public.imtbs-tsp.eu/~maigron/RIR_Stats/RIPE_Allocations/Allocs/C... was collected on Thu Dec 19 2019 and shows the equivalent of about 9.6 "B" blocks (I enclose it below). So the majority of those blocks appears to have changed LIR, leaving cz.relcom/AS2118-MNT to return to ROSNIIROS (aka RIPN) in the past 10 days. Example:
Facinating. It would be even more facinating to have someone from RIPE NCC come and explain to us all how it came to pass that something on the order of an alleged 490 thousand IPv4 addresses got transferred, allegedly illicitly, from a Russian company to a Czech company, AND what rules and standard procedures were followed in order to transfer these back to the Russian company... ... but I also asked for a unicorn for Christmas and I didn't get that either. :-) I guess that when Russia comes knocking, RIPE NCC submissively complies. I can only wish that they would do the same for me. Regards, rfg
![](https://secure.gravatar.com/avatar/1f6335590da3d7fe44697e44ee390206.jpg?s=120&d=mm&r=g)
Hi Ronald, How these things slip through is when paperwork gets submitted that is incorrect and falsified with fake signatures. Despite al the efforts that the RIPE NCC is taking to recognize fake / falsified documents ... On the topic how does it get reversed ... Typically one of the actual directors reports a theft of IP space to the RIPE NCC.. The RIPE NCC will then investigate and if things are incorrect, the legitimate holder can request a reverse of the IP space transfer. This obviously leaves the buyer ( typically one that paid a lot of money to a certain individual for the IP space ) ... without funds and without IP space. This is also why some if not most traders will/should walk away from certain deals if it isn't 100% clear who the actual legitimate holder of the IP space is and if the proper signatures aren't on the paperwork. Funds should always be deposited from an escrow into the bank account of the company that sells the IP space, never to a private bank account of a director or sister company ... Any other options that are requested are typical red flags for money laundering / fraudulent transactions .. Especially with international fraud, it is hard to get the funds back ... the buyer has little to no option to get the funds back and the one that received the funds are probably long gone. Regards, Erik Bais On 28/12/2019, 04:03, "anti-abuse-wg on behalf of Ronald F. Guilmette" <anti-abuse-wg-bounces@ripe.net on behalf of rfg@tristatelogic.com> wrote: In message <20191228020627.GA9820@allog.giato>, furio ercolessi <furio+as@spin.it> wrote: >On Fri, Dec 27, 2019 at 02:35:29PM -0800, Ronald F. Guilmette wrote: >> Anyone have more details about this? >> >> https://belsat.eu/en/news/runet-founder-under-house-arrest/ >> >> The Czech company that allagedly received the allegedly stolen >> 7.5 "B" blocks (/16) would seem to be this one: >> >> ORG-RCS23-RIPE >> AS15731 >> >> https://www.ripe.net/membership/indices/data/cz.relcom.html >> >> But I am not seeing that ORG as having quite that many IPv4 addresses >> assigned. >> >> Maybe the alleged perp in this case only stole IPv6 addresses (?) > >Hello Ron, > >in https://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt >under cz.relcom you can currently see the equivalent of about 2.6 "B" blocks. > >However, only 10 days they were apparently a lot more! For instance, the list at >https://www-public.imtbs-tsp.eu/~maigron/RIR_Stats/RIPE_Allocations/Allocs/C... >was collected on Thu Dec 19 2019 and shows the equivalent of about 9.6 "B" blocks >(I enclose it below). >So the majority of those blocks appears to have changed LIR, leaving cz.relcom/AS2118-MNT >to return to ROSNIIROS (aka RIPN) in the past 10 days. Example: Facinating. It would be even more facinating to have someone from RIPE NCC come and explain to us all how it came to pass that something on the order of an alleged 490 thousand IPv4 addresses got transferred, allegedly illicitly, from a Russian company to a Czech company, AND what rules and standard procedures were followed in order to transfer these back to the Russian company... ... but I also asked for a unicorn for Christmas and I didn't get that either. :-) I guess that when Russia comes knocking, RIPE NCC submissively complies. I can only wish that they would do the same for me. Regards, rfg
![](https://secure.gravatar.com/avatar/5a42e6028e8bb86507db584e26c73136.jpg?s=120&d=mm&r=g)
How these things slip through is when paperwork gets submitted that is incorrect and falsified with fake signatures.
and the ncc has a job advert out to hire even more lawyers (no blame; it's a mess). can ripe keep from becoming arin? randy
![](https://secure.gravatar.com/avatar/71b0a25163933fcaf5f3d59c8e65b7e6.jpg?s=120&d=mm&r=g)
Well the RIPE pay for a legal counsel isn't that great, so they probably aiming for a junior. As for the 'affair', legal wheels turn slowly, so most likely RIPE wasn't directly involved, so most likely 'Soldatov' was pressured into returning the ip-space as he is also co-owner of the Czech company. Looks like it was a two prong approach, sell/give the ip-space to a Czech company and use that vehicle to sell the ip-space for a profit. Money then is outside Putins hands, also no problems with 'sanctions' etc. But then again what do I know.-- IDGARA | Alex de Joode | +31651108221 On Sat, 28-12-2019 20h 09min, Randy Bush <randy@psg.com> wrote:
How these things slip through is when paperwork gets submitted that is
incorrect and falsified with fake signatures.
and the ncc has a job advert out to hire even more lawyers (no blame; it's a mess). can ripe keep from becoming arin?
randy
![](https://secure.gravatar.com/avatar/3f1c42a4f42626eeaa9a4dbd3de07126.jpg?s=120&d=mm&r=g)
+1 Randy Bush <randy@psg.com>于2019年12月29日 周日04:10写道:
How these things slip through is when paperwork gets submitted that is incorrect and falsified with fake signatures.
and the ncc has a job advert out to hire even more lawyers (no blame; it's a mess). can ripe keep from becoming arin?
randy
-- -- Kind regards. Lu
![](https://secure.gravatar.com/avatar/daa9ea618351eb68baad89b6dfab4f28.jpg?s=120&d=mm&r=g)
In message <CAAvCx3iky28KdLYYQ3Adubkj9i2gsTYv7GQxUzHK4MzcyV93MA@mail.gmail.com> Lu Heng <h.lu@anytimechinese.com> wrote:
+1
I should think so! Lu, as the owner of a great deal of legitimately acquired AFRINIC IPv4 space, I should think that you would be suitably outraged to see others committing fraud and/or other kinds of malfeasance in order to scam their way into the same sort of IPv4 space that you legitimately bought and paid for. All of these crooked schemes should quite rightly be an outrage to an honest man such as yourself. And for that reason I feel sure that you'll be dismayed to learn that you have... undoubtedly unintentionally... been paying at least some of your honest and hard earned money to obtain routing for a small sub-part of your sizable IPv4 holdings to a company that's rather unambiguously linked to yet another apparent IPv4 scam that was already outted some months ago by my friend, journalist Brian Krebs. I'm speaking specifically about your 154.81.1.0/24, 154.208.12.0/22, and 154.208.16.0/20 blocks, all of which are apparently currently being routed by a recently slapped together Virginia company named "Ting Wireless, LLC" and its apparent proprietor, Roy Tyree Franklin (age 31). https://opencorporates.com/companies/us_va/S7848650 As we speak, it appears that this company and its ASN, i.e. AS398083, is routing the above named blocks for you, and is also routing a number of blocks for a somewhat slippery company known as Residential Networking Solutions LLC, aka "RESNET", which Brian Krebs identified as being located in the state of Maryland (consistant with th 240 area code of the phone number on the company web site, resnet.io), but which at least some relevant RIPE WHOIS records (e.g. ORG-RI49-RIPE) suggest is actually located in Norwalk, Connecticut. Here's is Brian's article about this apparent scam from August: https://krebsonsecurity.com/2019/08/the-rise-of-bulletproof-residential-netw... Since the time of Brian's article, it seems that "RESNET" and its apparent sister company, Maryland Broadband, found the general ambiance rather less accomodating of their chicanery in the ARIN region, so they did the logical thing and started getting their IPv4 space from the always accomodating RIPE region, where no criminal with a good story and a freshly minted shell company is ever turned away, regardless of criminal past or present. So anyway, Lu, your blocks are being routed by Ting Wireless, LLC, right along with a bunch of others that I have more than a little reason to be suspicious about, specifically regarding their provenance. I feel sure that this horrifies you, just as it does me, and that thus, you'll help me to get to the bottom of it all. As a first step, I hope that you will introduce me to whoever it was who you contracted with at Ting Wireless in order to arrange for that company to route your blocks, which it is quite clearly doing, right along side all of the questionable stuff: https://bgp.he.net/AS398083#_prefixes Who did you send your check to at the fresh new company Ting Wireless, LLC? Would that have been Mr. Roy Tyree Franklin? Is that by any chance the exact same same high-end experienced and seasoned networking professional, Roy Tyree Franklin, who was busted on March 15, 2015, in Petersburg, Virginia for fishing without a license? https://www.pressreader.com/usa/the-progress-index/20150420/281573764231659 Like I always say, "Beware the Ides of March!" I have to say, I think that he would have been better served if he had been stringing cat6 that day, or maybe upgrading his A/C plant, rather than trawling for catfish. But that's just my opinion. Anyway, if you can arrange it, I would love to have you make a personal introduction so that I can maybe get to the bottom of this whole set of questions I have about this whole RESNET / Maryland Boradband thing. Please do let me know if you can do that. I don't see any reason why you wouldn't be able to do make connections for me, considering that you are clearly doing business with this company (Ting Wireless). Regards, rfg P.S. Brian said in his article that AT&T had told him that "“We have taken steps to terminate this company’s services and have referred the matter to law enforcement.” but I guess that whichever LE people AT&T spoke with, they have other more pressing things on their plates, and other fish to fry... no pun intended. So I guess it's up to me... again... to figure out what's actually going on here, and your kind assistance would be greatly appreciated.
![](https://secure.gravatar.com/avatar/58718afd29c61533d953ad36e2a27594.jpg?s=120&d=mm&r=g)
On 28/12/2019 21:09, Randy Bush wrote:
How these things slip through is when paperwork gets submitted that is incorrect and falsified with fake signatures. and the ncc has a job advert out to hire even more lawyers (no blame; it's a mess). can ripe keep from becoming arin?
randy
It would be nice if RIPE NCC could provide as part of its annual report a list of incidents of this nature so we have an idea of how wide-spread this is - or not. -Hank
![](https://secure.gravatar.com/avatar/5a42e6028e8bb86507db584e26c73136.jpg?s=120&d=mm&r=g)
It would be nice if RIPE NCC could provide as part of its annual report a list of incidents of this nature so we have an idea of how wide-spread this is - or not.
as i try not to indulge in schadenfreude, i don't have much use for this information. we spent some time in this space in rotterdam. the presos were well done, but not my cup of coffee. i am sure there were others who found it fascinating. i guess that's what makes the world go 'round. randy
![](https://secure.gravatar.com/avatar/a984d4fae7590cceeb9b11c6ff837a44.jpg?s=120&d=mm&r=g)
Dear colleagues, We would like to provide some clarification on this case. Earlier this year, we transferred a large number of IP addresses from the autonomous nonprofit organisation "Russian Scientific-Research Institute for Public Networks” in the Russian Federation to the Reliable Communications s.r.o in the Czech Republic. This change was processed by the RIPE NCC in full compliance with RIPE Policies and the RIPE NCC’s published procedures. Later, we received new information from both organisations about this transfer. It was then followed by an official request in which both parties asked us to revert the changes made to our registry and return the IP addresses back to their previous holders. After an internal review, we reverted the registration of the addresses. While we cannot disclose more details publicly, we would like to emphasise that we took this action within our mandate to maintain an up-to-date and correct Internet number resource registry, and as a neutral and impartial organisation. Kind regards and Happy New Year, Marco Schmidt Registration Services and Policy Development Assistant Manager RIPE NCC On 29/12/2019 06:45, Randy Bush wrote:
It would be nice if RIPE NCC could provide as part of its annual report a list of incidents of this nature so we have an idea of how wide-spread this is - or not. as i try not to indulge in schadenfreude, i don't have much use for this information.
we spent some time in this space in rotterdam. the presos were well done, but not my cup of coffee. i am sure there were others who found it fascinating. i guess that's what makes the world go 'round.
randy
![](https://secure.gravatar.com/avatar/71c29b82d9b8ef2516930d164d56c43b.jpg?s=120&d=mm&r=g)
Hi Marco,
Later, we received new information from both organisations about this transfer. It was then followed by an official request in which both parties asked us to revert the changes made to our registry and return the IP addresses back to their previous holders. After an internal review, we reverted the registration of the addresses.
Can you give some more details on the fact that policy requirements for holding the resources for 24 months after the transfer was suspended?
While we cannot disclose more details publicly, we would like to emphasise that we took this action within our mandate to maintain an up-to-date and correct Internet number resource registry, and as a neutral and impartial organisation.
The last sentence proves that there are rules and there are rules. How the NCC can be a neutral organisation while policy isn't applied to all members in an equal manner? Thank you and have a happy holidays. -- Kind regards, Sergey Myasoedov
On 31 Dec 2019, at 09:28, Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
We would like to provide some clarification on this case.
Earlier this year, we transferred a large number of IP addresses from the autonomous nonprofit organisation "Russian Scientific-Research Institute for Public Networks” in the Russian Federation to the Reliable Communications s.r.o in the Czech Republic. This change was processed by the RIPE NCC in full compliance with RIPE Policies and the RIPE NCC’s published procedures.
Later, we received new information from both organisations about this transfer. It was then followed by an official request in which both parties asked us to revert the changes made to our registry and return the IP addresses back to their previous holders. After an internal review, we reverted the registration of the addresses.
While we cannot disclose more details publicly, we would like to emphasise that we took this action within our mandate to maintain an up-to-date and correct Internet number resource registry, and as a neutral and impartial organisation.
Kind regards and Happy New Year,
Marco Schmidt Registration Services and Policy Development Assistant Manager RIPE NCC
On 29/12/2019 06:45, Randy Bush wrote:
It would be nice if RIPE NCC could provide as part of its annual report a list of incidents of this nature so we have an idea of how wide-spread this is - or not. as i try not to indulge in schadenfreude, i don't have much use for this information.
we spent some time in this space in rotterdam. the presos were well done, but not my cup of coffee. i am sure there were others who found it fascinating. i guess that's what makes the world go 'round.
randy
![](https://secure.gravatar.com/avatar/9f3bcbe021ee21cefda03deda04834b2.jpg?s=120&d=mm&r=g)
Dear Sergey, In this case, the transfer was ‘reverted’, meaning that the registration details prior to the transfer were restored. We see this action as an annulment of the original transfer and not a second transfer requiring implementation of the 24-month rule. With regards to implementing policies and procedures, we apply them as equally and neutrally as possible, but we also consider it reasonable and sensible to take extraordinary circumstances into account. On this occasion, RIPE NCC Management reviewed a case in which new information had come to light and it decided to act as it saw necessary and appropriate. Kind regards, Nikolas Pediaditis Registration Services and Policy Development Manager RIPE NCC
On 31 Dec 2019, at 21:13, Sergey Myasoedov via anti-abuse-wg <anti-abuse-wg@ripe.net> wrote:
Hi Marco,
Later, we received new information from both organisations about this transfer. It was then followed by an official request in which both parties asked us to revert the changes made to our registry and return the IP addresses back to their previous holders. After an internal review, we reverted the registration of the addresses.
Can you give some more details on the fact that policy requirements for holding the resources for 24 months after the transfer was suspended?
While we cannot disclose more details publicly, we would like to emphasise that we took this action within our mandate to maintain an up-to-date and correct Internet number resource registry, and as a neutral and impartial organisation.
The last sentence proves that there are rules and there are rules. How the NCC can be a neutral organisation while policy isn't applied to all members in an equal manner?
Thank you and have a happy holidays.
-- Kind regards, Sergey Myasoedov
On 31 Dec 2019, at 09:28, Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
We would like to provide some clarification on this case.
Earlier this year, we transferred a large number of IP addresses from the autonomous nonprofit organisation "Russian Scientific-Research Institute for Public Networks” in the Russian Federation to the Reliable Communications s.r.o in the Czech Republic. This change was processed by the RIPE NCC in full compliance with RIPE Policies and the RIPE NCC’s published procedures.
Later, we received new information from both organisations about this transfer. It was then followed by an official request in which both parties asked us to revert the changes made to our registry and return the IP addresses back to their previous holders. After an internal review, we reverted the registration of the addresses.
While we cannot disclose more details publicly, we would like to emphasise that we took this action within our mandate to maintain an up-to-date and correct Internet number resource registry, and as a neutral and impartial organisation.
Kind regards and Happy New Year,
Marco Schmidt Registration Services and Policy Development Assistant Manager RIPE NCC
On 29/12/2019 06:45, Randy Bush wrote:
It would be nice if RIPE NCC could provide as part of its annual report a list of incidents of this nature so we have an idea of how wide-spread this is - or not. as i try not to indulge in schadenfreude, i don't have much use for this information.
we spent some time in this space in rotterdam. the presos were well done, but not my cup of coffee. i am sure there were others who found it fascinating. i guess that's what makes the world go 'round.
randy
![](https://secure.gravatar.com/avatar/7376a38fd772fe1864cd25f80a719efa.jpg?s=120&d=mm&r=g)
Hi Nikolas, where in the policies are annulments possible? Elvis On Thu, Jan 2, 2020 at 06:30 Nikolas Pediaditis <npediaditi@ripe.net> wrote:
Dear Sergey,
In this case, the transfer was ‘reverted’, meaning that the registration details prior to the transfer were restored. We see this action as an annulment of the original transfer and not a second transfer requiring implementation of the 24-month rule.
With regards to implementing policies and procedures, we apply them as equally and neutrally as possible, but we also consider it reasonable and sensible to take extraordinary circumstances into account. On this occasion, RIPE NCC Management reviewed a case in which new information had come to light and it decided to act as it saw necessary and appropriate.
Kind regards,
Nikolas Pediaditis Registration Services and Policy Development Manager RIPE NCC
On 31 Dec 2019, at 21:13, Sergey Myasoedov via anti-abuse-wg < anti-abuse-wg@ripe.net> wrote:
Hi Marco,
Later, we received new information from both organisations about this transfer. It was then followed by an official request in which both parties asked us to revert the changes made to our registry and return the IP addresses back to their previous holders. After an internal review, we reverted the registration of the addresses.
Can you give some more details on the fact that policy requirements for holding the resources for 24 months after the transfer was suspended?
While we cannot disclose more details publicly, we would like to emphasise that we took this action within our mandate to maintain an up-to-date and correct Internet number resource registry, and as a neutral and impartial organisation.
The last sentence proves that there are rules and there are rules. How the NCC can be a neutral organisation while policy isn't applied to all members in an equal manner?
Thank you and have a happy holidays.
-- Kind regards, Sergey Myasoedov
On 31 Dec 2019, at 09:28, Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
We would like to provide some clarification on this case.
Earlier this year, we transferred a large number of IP addresses from the autonomous nonprofit organisation "Russian Scientific-Research Institute for Public Networks” in the Russian Federation to the Reliable Communications s.r.o in the Czech Republic. This change was processed by the RIPE NCC in full compliance with RIPE Policies and the RIPE NCC’s published procedures.
Later, we received new information from both organisations about this transfer. It was then followed by an official request in which both parties asked us to revert the changes made to our registry and return the IP addresses back to their previous holders. After an internal review, we reverted the registration of the addresses.
While we cannot disclose more details publicly, we would like to emphasise that we took this action within our mandate to maintain an up-to-date and correct Internet number resource registry, and as a neutral and impartial organisation.
Kind regards and Happy New Year,
Marco Schmidt Registration Services and Policy Development Assistant Manager RIPE NCC
It would be nice if RIPE NCC could provide as part of its annual report a list of incidents of this nature so we have an idea of how wide-spread this is - or not. as i try not to indulge in schadenfreude, i don't have much use for
On 29/12/2019 06:45, Randy Bush wrote: this
information.
we spent some time in this space in rotterdam. the presos were well done, but not my cup of coffee. i am sure there were others who found it fascinating. i guess that's what makes the world go 'round.
randy
-- This message was sent from a mobile device. Some typos may be possible.
![](https://secure.gravatar.com/avatar/9f3bcbe021ee21cefda03deda04834b2.jpg?s=120&d=mm&r=g)
Hi Elvis and all, The RIPE NCC's procedural and legal framework for the implementation of the RIPE policies allow the RIPE NCC to revert transfers in exceptional circumstances. This is mentioned in the transfer agreement that both parties have to sign (article 2.6): https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran... More generally, and as we often state, we cannot publicly discuss the details of individual cases. This is important, both legally and in order to maintain the trust of our members. It can be difficult as speculation and incorrect information about cases can sometimes make its way to the media or to mailing lists and we are unable to provide detailed information. However, we can assure the members and community that we fairly implement the policies decided by the community within a strong legal framework and in accordance with our published procedures. Kind regards, Nikolas Pediaditis Registration Services and Policy Development Manager RIPE NCC
On 2 Jan 2020, at 19:34, Elvis Daniel Velea <elvis@v4escrow.net> wrote:
Hi Nikolas,
where in the policies are annulments possible?
Elvis
On Thu, Jan 2, 2020 at 06:30 Nikolas Pediaditis <npediaditi@ripe.net> wrote: Dear Sergey,
In this case, the transfer was ‘reverted’, meaning that the registration details prior to the transfer were restored. We see this action as an annulment of the original transfer and not a second transfer requiring implementation of the 24-month rule.
With regards to implementing policies and procedures, we apply them as equally and neutrally as possible, but we also consider it reasonable and sensible to take extraordinary circumstances into account. On this occasion, RIPE NCC Management reviewed a case in which new information had come to light and it decided to act as it saw necessary and appropriate.
Kind regards,
Nikolas Pediaditis Registration Services and Policy Development Manager RIPE NCC
On 31 Dec 2019, at 21:13, Sergey Myasoedov via anti-abuse-wg <anti-abuse-wg@ripe.net> wrote:
Hi Marco,
Later, we received new information from both organisations about this transfer. It was then followed by an official request in which both parties asked us to revert the changes made to our registry and return the IP addresses back to their previous holders. After an internal review, we reverted the registration of the addresses.
Can you give some more details on the fact that policy requirements for holding the resources for 24 months after the transfer was suspended?
While we cannot disclose more details publicly, we would like to emphasise that we took this action within our mandate to maintain an up-to-date and correct Internet number resource registry, and as a neutral and impartial organisation.
The last sentence proves that there are rules and there are rules. How the NCC can be a neutral organisation while policy isn't applied to all members in an equal manner?
Thank you and have a happy holidays.
-- Kind regards, Sergey Myasoedov
On 31 Dec 2019, at 09:28, Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
We would like to provide some clarification on this case.
Earlier this year, we transferred a large number of IP addresses from the autonomous nonprofit organisation "Russian Scientific-Research Institute for Public Networks” in the Russian Federation to the Reliable Communications s.r.o in the Czech Republic. This change was processed by the RIPE NCC in full compliance with RIPE Policies and the RIPE NCC’s published procedures.
Later, we received new information from both organisations about this transfer. It was then followed by an official request in which both parties asked us to revert the changes made to our registry and return the IP addresses back to their previous holders. After an internal review, we reverted the registration of the addresses.
While we cannot disclose more details publicly, we would like to emphasise that we took this action within our mandate to maintain an up-to-date and correct Internet number resource registry, and as a neutral and impartial organisation.
Kind regards and Happy New Year,
Marco Schmidt Registration Services and Policy Development Assistant Manager RIPE NCC
On 29/12/2019 06:45, Randy Bush wrote:
It would be nice if RIPE NCC could provide as part of its annual report a list of incidents of this nature so we have an idea of how wide-spread this is - or not. as i try not to indulge in schadenfreude, i don't have much use for this information.
we spent some time in this space in rotterdam. the presos were well done, but not my cup of coffee. i am sure there were others who found it fascinating. i guess that's what makes the world go 'round.
randy
-- This message was sent from a mobile device. Some typos may be possible.
![](https://secure.gravatar.com/avatar/71c29b82d9b8ef2516930d164d56c43b.jpg?s=120&d=mm&r=g)
Hi Nikolas, Thank you for your explanation, I appreciate it.
On 2 Jan 2020, at 14:29, Nikolas Pediaditis <npediaditi@ripe.net> wrote:
With regards to implementing policies and procedures, we apply them as equally and neutrally as possible, but we also consider it reasonable and sensible to take extraordinary circumstances into account. On this occasion, RIPE NCC Management reviewed a case in which new information had come to light and it decided to act as it saw necessary and appropriate.
I do believe that the extraordinary circumstances are when the ER department is involved in the process. But usually RIPE NCC don't perform the rollback of transfers. In the case we've seen, two members are still active, no M&A deal, but suddenly Ministry of foreign affairs got involved, crime investigation is ongoing... In the similar circumstances in Kazakhstan (2018-2019) the NCC decided not to make any statements in the court and didn't revert the transaction until the Supreme court made its decision. The unpredictability of the NCC's actions don't make the members happy. -- Kind regards, Sergey Myasoedov
![](https://secure.gravatar.com/avatar/5a42e6028e8bb86507db584e26c73136.jpg?s=120&d=mm&r=g)
The unpredictability of the NCC's actions don't make the members happy.
s/the members/you/ at least in this case. and maybe a few others. i, for one, am not unhappy, except that you speak for me. randy
![](https://secure.gravatar.com/avatar/29943efe6e0ec32f29967a3a1b40145b.jpg?s=120&d=mm&r=g)
Sergey You DO NOT speak for all members. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 On 02/01/2020, 19:34, "anti-abuse-wg on behalf of Sergey Myasoedov via anti-abuse-wg" <anti-abuse-wg-bounces@ripe.net on behalf of anti-abuse-wg@ripe.net> wrote: Hi Nikolas, Thank you for your explanation, I appreciate it. > On 2 Jan 2020, at 14:29, Nikolas Pediaditis <npediaditi@ripe.net> wrote: > > With regards to implementing policies and procedures, we apply them as equally and neutrally as possible, but we also consider it reasonable and sensible to take extraordinary circumstances into account. On this occasion, RIPE NCC Management reviewed a case in which new information had come to light and it decided to act as it saw necessary and appropriate. I do believe that the extraordinary circumstances are when the ER department is involved in the process. But usually RIPE NCC don't perform the rollback of transfers. In the case we've seen, two members are still active, no M&A deal, but suddenly Ministry of foreign affairs got involved, crime investigation is ongoing... In the similar circumstances in Kazakhstan (2018-2019) the NCC decided not to make any statements in the court and didn't revert the transaction until the Supreme court made its decision. The unpredictability of the NCC's actions don't make the members happy. -- Kind regards, Sergey Myasoedov
![](https://secure.gravatar.com/avatar/7464051f6e3699c7fe501681b53d8c48.jpg?s=120&d=mm&r=g)
I am not a member. However, the increase in such incidents and the risk of regulators or lawsuits occurring mean that RIPE NCC does need to perform more due diligence than would be consistent with a “we are not the internet police” position. It is in their own members’ interest that they’re able to detect when some malefactor approaches them with clumsily forged paperwork, newly created shell companies pretending to be companies that were dissolved two decades ago etc and tries to hijack a netblock. If a bank manager were to extend loans based on such paperwork with maybe as much due diligence appears to be performed during transfers.. --srs From: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> Date: Friday, 3 January 2020 at 6:08 PM To: Sergey Myasoedov <sergey@devnull.ru>, Nikolas Pediaditis <npediaditi@ripe.net> Cc: anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] [routing-wg] An arrest in Russia Sergey You DO NOT speak for all members. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 On 02/01/2020, 19:34, "anti-abuse-wg on behalf of Sergey Myasoedov via anti-abuse-wg" <anti-abuse-wg-bounces@ripe.net on behalf of anti-abuse-wg@ripe.net> wrote: Hi Nikolas, Thank you for your explanation, I appreciate it. > On 2 Jan 2020, at 14:29, Nikolas Pediaditis <npediaditi@ripe.net> wrote: > > With regards to implementing policies and procedures, we apply them as equally and neutrally as possible, but we also consider it reasonable and sensible to take extraordinary circumstances into account. On this occasion, RIPE NCC Management reviewed a case in which new information had come to light and it decided to act as it saw necessary and appropriate. I do believe that the extraordinary circumstances are when the ER department is involved in the process. But usually RIPE NCC don't perform the rollback of transfers. In the case we've seen, two members are still active, no M&A deal, but suddenly Ministry of foreign affairs got involved, crime investigation is ongoing... In the similar circumstances in Kazakhstan (2018-2019) the NCC decided not to make any statements in the court and didn't revert the transaction until the Supreme court made its decision. The unpredictability of the NCC's actions don't make the members happy. -- Kind regards, Sergey Myasoedov
![](https://secure.gravatar.com/avatar/fcc7b58a306a02e8bbed2a2a08c64909.jpg?s=120&d=mm&r=g)
Hi, On Fri, Jan 03, 2020 at 03:55:07PM +0000, Suresh Ramasubramanian wrote:
I am not a member. However, the increase in such incidents and the risk of regulators or lawsuits occurring mean that RIPE NCC does need to perform more due diligence than would be consistent with a ???we are not the internet police??? position.
On everything registry-related, the NCC does huge amounts of due dilligence. This has nothing to do whatsoever with *routing* police'ing, though. Gert Doering -- member, and occasionally on the wrong end of the due dilligence -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
![](https://secure.gravatar.com/avatar/7464051f6e3699c7fe501681b53d8c48.jpg?s=120&d=mm&r=g)
So the RIR has absolutely no role in maintaining say IRR data? I agree validating LOAs and such for routing changes would be on providers. Though if the changes were to be made in IRR data who would validate it? --srs From: Gert Doering <gert@space.net> Date: Friday, 3 January 2020 at 9:32 PM To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Michele Neylon - Blacknight <michele@blacknight.com>, Sergey Myasoedov <sergey@devnull.ru>, Nikolas Pediaditis <npediaditi@ripe.net>, anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] [routing-wg] An arrest in Russia Hi, On Fri, Jan 03, 2020 at 03:55:07PM +0000, Suresh Ramasubramanian wrote:
I am not a member. However, the increase in such incidents and the risk of regulators or lawsuits occurring mean that RIPE NCC does need to perform more due diligence than would be consistent with a ???we are not the internet police??? position.
On everything registry-related, the NCC does huge amounts of due dilligence. This has nothing to do whatsoever with *routing* police'ing, though. Gert Doering -- member, and occasionally on the wrong end of the due dilligence -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
![](https://secure.gravatar.com/avatar/5a42e6028e8bb86507db584e26c73136.jpg?s=120&d=mm&r=g)
I am not a member. However, the increase in such incidents and the risk of regulators or lawsuits occurring mean that RIPE NCC does need to perform more due diligence than would be consistent with a “we are not the internet police” position.
if this is an accusation that they are not, then you have become quite plonkable randy
![](https://secure.gravatar.com/avatar/daa9ea618351eb68baad89b6dfab4f28.jpg?s=120&d=mm&r=g)
In message <SG2PR03MB4053A9AE3E9612CBD66D6EBFF5230@SG2PR03MB4053.apcprd03.prod. outlook.com>, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
It is in their own members’ interest that they’re able to detect when some malefactor approaches them with clumsily forged paperwork, newly created shell companies pretending to be companies that were dissolved two decades ago etc and tries to hijack a netblock.
Although I'll always be in agreement with the general notion that RIRs have a responsibility to perform sound and adequate due diligence with respect to all transfers and allocations, I think that Suresh's comments here are a bit out of place with respect to this specific case. Here, it seems, based on the public reports, all of the i's were dotted, and all of the t's were crossed, and there was even a formal written endorsement of the transfer from some big shot associated with the original Russian registrant of the resources in question. There's no evidence on the table that there was any involvement in this instance of any shell companies or anything like that, so I, for one, have trouble finding fault with anything that NCC did in this case. RIRs -are- going to flim-flammed from time to time. Just ask ARIN about the Micfo case. Even banks get flim-flammed now and then. If someone is hell bent on running a con, and has sufficient time, resources, creativity, and, as seems to be true in this case, also has some insider participating in the whole scheme, then there's not a lot that can be done other than to request law enforcement to get involved, after the fact, which it appears has already taken place in this case. Regards, rfg
![](https://secure.gravatar.com/avatar/daa9ea618351eb68baad89b6dfab4f28.jpg?s=120&d=mm&r=g)
In message <69b2d60c-2b9c-104b-a1fe-63318aa30092@ripe.net>, Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
We would like to provide some clarification on this case. {...snipped...}
I just want to thank Marco and the whole NCC team for providing further information on this quite unusual situation. They were not necessarily obliged to do so, but it is Good that they did. In all respects, it would certainly appear that NCC handled this matter professionally, appropriately, and in a timely manner, entirely consistant with established policy and procedures. It is arguably unfortunate that they were obliged to do so by these unique and unusual events. Both they and the community can hope that, in the future, these kinds of things won't come up again, but given the ever increasing value of IPv4 assets I suspect that we should all be girding ourselves for a future in which such funny business may, alas, become routine. Happy New Year to all! Regards, rfg
![](https://secure.gravatar.com/avatar/c512c2e8c622bd1a40f006d8008898c0.jpg?s=120&d=mm&r=g)
On Fri, Dec 27, 2019 at 02:35:29PM -0800, Ronald F. Guilmette wrote:
Anyone have more details about this?
http://www.compromat.ru/page_40907.htm (in russian) contains more details. furio ercolessi
participants (15)
-
Alex de Joode
-
Elvis Daniel Velea
-
Erik Bais
-
furio ercolessi
-
Gert Doering
-
Hank Nussbacher
-
Lu Heng
-
Marco Schmidt
-
Michele Neylon - Blacknight
-
Nikolas Pediaditis
-
Randy Bush
-
Ronald F. Guilmette
-
Sergey Myasoedov
-
Suresh Ramasubramanian
-
Töma Gavrichenkov