Re: AFRINIC IP Block Thefts -- The Saga Continues
That's it, the defamation gone too far, I'm not going to wait until I will win the legal proceedings against AfriNIC, I'm going to start legal proceedings against Ronald Guilmette, Jan Vermeulen (and MyBroadband) now. Please forgive me, for not doing it before and letting Ronald Guilmette spam Nanog and other mailing lists with his pores of lies, the illegal anonymous community Ops-Trust definitely know how to keep anyone that they would like busy, besides me being out of hospital in the end of last year and needed months for recovery. Anyone that is interested to receive any answer from me, please email me directly, I will say that Ronald Guilmette is intentionally spreading lies, and for the sake of Nanog community I will not reply to him over and over in the same coin, I was gladly interested in the past to share all the information (including AfriNIC legal proceedings) with a person respected by the Nanog community (and I'm still interested to do so today), such as William Herrin, or to anyone else respected by the Nanog community. Now, if any Ops-Trust community member (https://portal.ops-trust.net/) will want to try to had "proofless credibility" to Ronald Guilmette filthy pores of imagination (like "anyone with half brain will believe Ronald Guilmette" or "Cohen is sitting with impunity in Israel") - go ahead, it doesn't change the fact that you will do it without a single proof and that you are a mob of criminals, accepting new Ops-Trust community members only base on vouching and they share illegal private data secretly in their platform, according to Ops-Trust community private presentations: https://www.docdroid.net/xfaKhhY/f41lf3st2015-trident-toothed-and-pronged-pdf https://www.docdroid.net/xqTWVQW/first-2014-vixie-paul-op-sec-trust-pdf And if anyone in Nanog is interested in meaningless things such as: "truth", "facts" and "data": AfriNIC over a period of years, received more than 44 email notifications to their central email address (hostmas...@afrinic.net , due to the "notify:" attribute value and to the "--list-versions" output) regarding to updates that they themsleves made to legacy netblocks that I purchased legally, in what AfriNIC and Ronald Guillmette and Jan Vermeulen are calling "misappropriation". If anyone can explain that to me I will be thankful. One more thing I would like to add, Ronald Guilmette is the lawless one according to old scriptures, Ronald Guilmette match one by one to the description of the lawless one in old scriptures: - Ronald is blond. - Ronald is bald. - Ronald's one eye is bigger than the other. - Ronald's one arm is bigger than the other. - Ronald have leprosy in his forehead. - Ronald's right ear is blocked and the left ear is opened. (it is written in old scriptures: that when a person is coming to him to tell good things about people he gives him the blocked right ear, and when a person is coming to him to tell bad things about people he gives him the opened left ear). Ronald, will you show us a picture and a health report to prove that you are not the lawless one? Let me summarize: you will not do it. Do you know what are the motives of the lawless one? Deception and lies, like our pore-spilling friend, Ronald here. Ronald, and an additional personal note to you, you are a very very misery person, that have nothing and no one in your life, besides your pores, and you are defaming me and writing lies only for the attention, to feel "needed", to receive the "likeness" of people that don't have any courage to write defamation lies by themselves and are just using you, go get help and the sooner the better. From: NANOG on behalf of Ronald F. Guilmette Sent: Monday, November 16, 2020 6:00 AM To: nanog@nanog.org Subject: AFRINIC IP Block Thefts -- The Saga Continues South African tech journalist Jan Vermeulen has written a new chapter in this ongoing saga of greed, theft, and skulduggery. EXECUTIVE SUMMARY: Maikel Uerlings and Elad Cohen registered a bunch of new domain names as part of their overall scheme to steal AFRINIC legacy blocks by fiddling the AFRINIC WHOIS records for the contact persons for each legacy block that they wanted to steal. The domain names themselves were deliberately chosen and tailored to try to minimize suspicion relating to their numerous legacy block thefts. https://mybroadband.co.za/news/security/367188-the-great-african-ip-address-heist-south-african-internet-resources-worth-r558-million-usurped-with-shady-domains.html How exactly these two gentlemen managed to gain the kind of read/write access to the AFRINIC WHOIS data base which allowed them to fiddle so many WHOIS records for so many AFRINIC legacy IPv4 blocks is something that AFRINIC has yet to offer any explanation for, even a full year after these thefts came to light. NOTE: As of the present moment AFRINIC is *still* delegating authority for reverse DNS for many of the
Re: Telia Not Withdrawing v6 Routes
Maybe? Never been an issue before. In this case the route does have a depref community on Telia hence why one wouldn’t expect it via the same path, but the other ghost route in question never had anything similar. Matt > On Nov 15, 2020, at 23:07, Olivier Benghozi > wrote: > > One of the routing gears on the path don't like the large community inside > those routes maybe ? :) > By the way we currently see 2620:6e:a002::/48 at LINX LON1 from Choopa and > HE... > >> Le 16 nov. 2020 à 04:44, Matt Corallo a écrit : >> >> Yea, I did try that on that test prefix but it just stuck around anyway.. I >> don't care too much, its just some stale test prefix. >> >> Sadly, I now see it again with 2620:6e:a002::/48, which, somewhat more >> impressively, is now generating a routing loop Ashburn <-> NYC, and has >> always been announced from other places has was dropped/re-announced as wel. >> >> Must just be something with my particular prefixes, oh well. >> >> Matt >> >>> On 11/15/20 10:40 PM, Olivier Benghozi wrote: >>> Probably a ghost route. Such thing happens :( >>> https://labs.ripe.net/Members/romain_fontugne/bgp-zombies >>> Their (nice) LG shows that it's still advertised from a router of theirs in >>> Frankfurt (iBGP next hop :::2.255.251.224 – so by the way they use 6PE). >>> Your best option would probably be to re-advertise the exact same prefix, >>> then re-withdraw it, then yell at Telia's NOC if it fails... >>> Some years ago we experienced something similar (it was a router of TI >>> Sparkle still advertising a prefix of us in Asia to their clients, that >>> they were previously receiving from our former transit GTT – we were >>> advertising it in Europe...). Le 16 nov. 2020 à 02:58, Matt Corallo a écrit : Has anyone else experienced issues where Telia won't withdraw (though will happily accept an overriding) prefixes for the past week, at least? eg 2620:6e:a003::/48 was a test prefix and should not now appear in any DFZ, has not been announced for a few days at least, but shows up in Telia's LG and RIPE RIS as transiting Telia. Telia's LG traceroute doesn't of course, go anywhere, traces die immediately after a hop or with a !N. Wouldn't be a problem except that I needed to withdraw another route due to a separate issue which wouldn't budge out of Telia's tables until it was replaced with something else of higher pref. Matt >
Re: Telia Not Withdrawing v6 Routes
One of the routing gears on the path don't like the large community inside those routes maybe ? :) By the way we currently see 2620:6e:a002::/48 at LINX LON1 from Choopa and HE... > Le 16 nov. 2020 à 04:44, Matt Corallo a écrit : > > Yea, I did try that on that test prefix but it just stuck around anyway.. I > don't care too much, its just some stale test prefix. > > Sadly, I now see it again with 2620:6e:a002::/48, which, somewhat more > impressively, is now generating a routing loop Ashburn <-> NYC, and has > always been announced from other places has was dropped/re-announced as wel. > > Must just be something with my particular prefixes, oh well. > > Matt > > On 11/15/20 10:40 PM, Olivier Benghozi wrote: >> Probably a ghost route. Such thing happens :( >> https://labs.ripe.net/Members/romain_fontugne/bgp-zombies >> Their (nice) LG shows that it's still advertised from a router of theirs in >> Frankfurt (iBGP next hop :::2.255.251.224 – so by the way they use 6PE). >> Your best option would probably be to re-advertise the exact same prefix, >> then re-withdraw it, then yell at Telia's NOC if it fails... >> Some years ago we experienced something similar (it was a router of TI >> Sparkle still advertising a prefix of us in Asia to their clients, that they >> were previously receiving from our former transit GTT – we were advertising >> it in Europe...). >>> Le 16 nov. 2020 à 02:58, Matt Corallo a écrit : >>> >>> Has anyone else experienced issues where Telia won't withdraw (though will >>> happily accept an overriding) prefixes for the past week, at least? >>> >>> eg 2620:6e:a003::/48 was a test prefix and should not now appear in any >>> DFZ, has not been announced for a few days at least, but shows up in >>> Telia's LG and RIPE RIS as transiting Telia. Telia's LG traceroute doesn't >>> of course, go anywhere, traces die immediately after a hop or with a !N. >>> >>> Wouldn't be a problem except that I needed to withdraw another route due to >>> a separate issue which wouldn't budge out of Telia's tables until it was >>> replaced with something else of higher pref. >>> >>> Matt
AFRINIC IP Block Thefts -- The Saga Continues
South African tech journalist Jan Vermeulen has written a new chapter in this ongoing saga of greed, theft, and skulduggery. EXECUTIVE SUMMARY: Maikel Uerlings and Elad Cohen registered a bunch of new domain names as part of their overall scheme to steal AFRINIC legacy blocks by fiddling the AFRINIC WHOIS records for the contact persons for each legacy block that they wanted to steal. The domain names themselves were deliberately chosen and tailored to try to minimize suspicion relating to their numerous legacy block thefts. https://mybroadband.co.za/news/security/367188-the-great-african-ip-address-heist-south-african-internet-resources-worth-r558-million-usurped-with-shady-domains.html How exactly these two gentlemen managed to gain the kind of read/write access to the AFRINIC WHOIS data base which allowed them to fiddle so many WHOIS records for so many AFRINIC legacy IPv4 blocks is something that AFRINIC has yet to offer any explanation for, even a full year after these thefts came to light. NOTE: As of the present moment AFRINIC is *still* delegating authority for reverse DNS for many of the stolen legacy blocks detailed in Jan's most recent article to name servers that are owned and controled by Maikel Uerlings and/or Elad Cohen. In particular, Uerlings and/or Cohen are still in control of the reverse DNS for all of the stolen legacy blocks listed in the table below, as well as the reverse DNS for the very valuable 196.16.0.0/14 block, worth well over $5 million USD. There is no reasonable excuse for this ongoing inaction by AFRINIC. As things stand, it appears that AFRINIC is still refusing to do even the minimum amount necessary to stop the profiteering of Uerlings and Cohen, EVEN THOUGH every additional dollar, every additional sheckel, and every additional ruble that they earn from these ongoing thefts is being used to fund Cohen's ongoing lawsuit against AFRINIC. AFRINIC has known about these legacy block thefts for well over a year now, and yet in all this time AFRINIC has done absolutely nothing to remediate the fradulent entries in their WHOIS data base, or to remove the reverse DNS relegations for the 196.16.0.0/14 block and the several stolen blocks listed below. Reasonable people can and should ask why. One theory, currently circulating among people I know is that Mr. Uerlings and/or Mr. Cohen are in possession of some confidential information that AFRINIC really hopes will never see the light of day, and that AFRINIC is being blackmailed into inaction. Whatever the reason, AFRINIC's continuing inaction is effectively providing funding for Mr. Cohen's ongoing lawsuit against AFRINIC. How this makes any sense at all is something that remains for AFRINIC to explain. # # ORG: (SC) ORG-AISL1-AFRINIC "AECI Information Services (Pty) Ltd" # 168.80.0.0/15 # # ORG: (ZA) ORG-AA79-AFRINIC "Agrihold" # 163.198.0.0/16 # # ORG: (ZA) ORG-ACSL2-AFRINIC "Affiliated Computing Services (Pty) Ltd" # 160.116.0.0/16 # # ORG: (ZA) ORG-FSED1-AFRINIC "Free State Education Department" # 168.76.0.0/19 168.76.36.0/24 168.76.128.0/20 168.76.144.0/22 168.76.148.0/24 168.76.228.0/22 168.76.232.0/21 168.76.240.0/20 # # ORG: (ZA) ORG-SCS1-AFRINIC "Safren Computer Services" # 155.159.0.0/16
Re: Telia Not Withdrawing v6 Routes
Yea, I did try that on that test prefix but it just stuck around anyway.. I don't care too much, its just some stale test prefix. Sadly, I now see it again with 2620:6e:a002::/48, which, somewhat more impressively, is now generating a routing loop Ashburn <-> NYC, and has always been announced from other places has was dropped/re-announced as wel. Must just be something with my particular prefixes, oh well. Matt On 11/15/20 10:40 PM, Olivier Benghozi wrote: Probably a ghost route. Such thing happens :( https://labs.ripe.net/Members/romain_fontugne/bgp-zombies Their (nice) LG shows that it's still advertised from a router of theirs in Frankfurt (iBGP next hop :::2.255.251.224 – so by the way they use 6PE). Your best option would probably be to re-advertise the exact same prefix, then re-withdraw it, then yell at Telia's NOC if it fails... Some years ago we experienced something similar (it was a router of TI Sparkle still advertising a prefix of us in Asia to their clients, that they were previously receiving from our former transit GTT – we were advertising it in Europe...). Le 16 nov. 2020 à 02:58, Matt Corallo a écrit : Has anyone else experienced issues where Telia won't withdraw (though will happily accept an overriding) prefixes for the past week, at least? eg 2620:6e:a003::/48 was a test prefix and should not now appear in any DFZ, has not been announced for a few days at least, but shows up in Telia's LG and RIPE RIS as transiting Telia. Telia's LG traceroute doesn't of course, go anywhere, traces die immediately after a hop or with a !N. Wouldn't be a problem except that I needed to withdraw another route due to a separate issue which wouldn't budge out of Telia's tables until it was replaced with something else of higher pref. Matt
Re: Telia Not Withdrawing v6 Routes
Probably a ghost route. Such thing happens :( https://labs.ripe.net/Members/romain_fontugne/bgp-zombies Their (nice) LG shows that it's still advertised from a router of theirs in Frankfurt (iBGP next hop :::2.255.251.224 – so by the way they use 6PE). Your best option would probably be to re-advertise the exact same prefix, then re-withdraw it, then yell at Telia's NOC if it fails... Some years ago we experienced something similar (it was a router of TI Sparkle still advertising a prefix of us in Asia to their clients, that they were previously receiving from our former transit GTT – we were advertising it in Europe...). > Le 16 nov. 2020 à 02:58, Matt Corallo a écrit : > > Has anyone else experienced issues where Telia won't withdraw (though will > happily accept an overriding) prefixes for the past week, at least? > > eg 2620:6e:a003::/48 was a test prefix and should not now appear in any DFZ, > has not been announced for a few days at least, but shows up in Telia's LG > and RIPE RIS as transiting Telia. Telia's LG traceroute doesn't of course, go > anywhere, traces die immediately after a hop or with a !N. > > Wouldn't be a problem except that I needed to withdraw another route due to a > separate issue which wouldn't budge out of Telia's tables until it was > replaced with something else of higher pref. > > Matt
Re: Telia Not Withdrawing v6 Routes
This same issue happened in Los Angeles a number of years ago, but for IPv4 and v6. They need to setup sane BGP timers, and/or advocate the use of BFD for BGP sessions both customer facing and internal. Ryan On Nov 15 2020, at 5:58 pm, Matt Corallo wrote: > Has anyone else experienced issues where Telia won't withdraw (though will > happily accept an overriding) prefixes for > the past week, at least? > > eg 2620:6e:a003::/48 was a test prefix and should not now appear in any DFZ, > has not been announced for a few days at > least, but shows up in Telia's LG and RIPE RIS as transiting Telia. Telia's > LG traceroute doesn't of course, go > anywhere, traces die immediately after a hop or with a !N. > > Wouldn't be a problem except that I needed to withdraw another route due to a > separate issue which wouldn't budge out of > Telia's tables until it was replaced with something else of higher pref. > > Matt
Telia Not Withdrawing v6 Routes
Has anyone else experienced issues where Telia won't withdraw (though will happily accept an overriding) prefixes for the past week, at least? eg 2620:6e:a003::/48 was a test prefix and should not now appear in any DFZ, has not been announced for a few days at least, but shows up in Telia's LG and RIPE RIS as transiting Telia. Telia's LG traceroute doesn't of course, go anywhere, traces die immediately after a hop or with a !N. Wouldn't be a problem except that I needed to withdraw another route due to a separate issue which wouldn't budge out of Telia's tables until it was replaced with something else of higher pref. Matt
