April 2020 - members-discuss - mailman.ripe.net

Mailing List Purpose and Request for Consideration
by Piotr Strzyżewski 01 May '20

01 May '20

Dear all, I would like to remind you of the purpose of this list. It is to allow members to discuss matters of importance relating to their membership of the RIPE NCC. All other topics should be considered not relevant for this list. The Board is always pleased to see good discussion on the list, and we realise this can become heated at times. However, thousands of members are subscribed to the list and receive these emails. Therefore, I ask you to be considerate of your fellow members in terms of both content and frequency of mails. For those who wish to unsubscribe, please read the information available at: https://www.ripe.net/participate/member-support/membership-mailing-lists/su… Kind regards, Piotr Strzyżewski RIPE NCC Executive Board Secretary

2 1

Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
by Elad Cohen 01 May '20

01 May '20

Hello Ripe Members! I will share the following solution in the near General Meeting and I'm interested to share the following technical solution with you as well, it will completely resolve: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking. And will dramatically lower: IoT botnet infections and Botnet C&Cs. By a single update to any BGP router, not any router needs to be updated, only active BGP routers. If I will have the honor of being elected to the Ripe Board I will harness all the power of Ripe and all of the 5 RIR's and all of the LIR's in the 5 RIR's so routing manufacturing companies will implement the below processes and methods with a single firmware update to their BGP routers. I'm asking for your support in electing me so I will be able to enter the Ripe Board and then I will be able to make everything which is written in this post to come true. Regarding the bgp-anycasted infrastructure written below, ICANN is written but the global bgp-anycasted infrastructure can be managed by the 5 RIR's and/or by the ccTLDs registries (my main point is that who will operate the bgp-anycasted infrastructure is not important for now, as long as it will be an agreed authoritative non-governmental non-commercial global entity/ies) With new tracking protocol over ip, routers will be able to confirm that source ip came from the network of the announcing ASN, and hence spoofed amplification DDoS attacks will be completely annihilated. The Process: At the source BGP router, for any ip packet with a source address that is from the network of the source BGP router (lets call it original ip packet) - the source BGP router will create a new ip packet (lets call it tracking ip packet) with a new transport layer protocol and with the same source address and with the same destination address and with the same IP-ID such as the original ip packet. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router The destination BGP router (a BGP router that the destination address is in its network) whenever it receive a 'tracking ip packet' will check if its have the internal boolean 'Check tracking flag' in it - 'on' or 'off': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it if yes then to drop the tracking ip packet and to forward the related original ip packet to destination but only if the source address is originated from the specific ASN (according to the local ASNs+ranges table in the BGP router, such table will be received from ICANN) If the 'Check tracking flag' is set to 'on' then any original ip packet that arrive to the destination BGP router will wait for the related tracking ip packet (in case the related tracking ip packet didn't already arrived to the destination BGP router). The destination BGP router will manage such waiting for X number of seconds. The destination BGP router will match between a tracking ip packet and an original ip packet - based on their source address and their destination address and their IP-ID which will all be identical. More Aspects: - The end-devices will not need to be updated, any router will not need to be updated, only all the BGP routers will need to be updated. - Any BGP router in the routing path, which the original ip packet and the tracking ip packet are not destined to an ip address in its own network - will not check the content of the tracking ip packet and will forward both the tracking ip packet and the original ip packet as they are. - Each BGP router will have all the public keys (of all the ASN's) locally. - Each BGP router will have a full list of all the ASN's and all the route objects ranges which are related to them locally. How BGP routers will receive all the ranges in all the route objects of all the ASNs (in the 5 RIRs) and all the public keys of all the ASNs (for decrypting the encrypted strings in 'tracking ip packets'): - Each BGP router will create a tcp session with ICANN backend infrastructure (the backend infrastructure of ICANN will use BGP anycast and will be available from many locations worldwide with automatic syncing) - At this stage there will be a handshake process between the BGP router and the ICANN backend infrastructure in order for ICANN to know the correct ASN which is operating the BGP router - the BGP router will send its ASN in cleartext and also its ASN encrypted with its ICANN-communication-private-key , ICANN will know the related public key for the specific ASN from the specific ASN object in the RIR (the public key for communication with ICANN will be displayed there) - after decryption ICANN will compare the decrypted string to the AS Number for successful authentication. - After successful authentication, all the communication will be encrypted, ICANN will notify the BGP router about its public key and ICANN will use the public key of the ASN for the communication with ICANN - from the ASN object in the RIR. - The BGP router will send over the session its public key to be used by other BGP routers in order to decrypt the encrypted string in the tracking ip packets that it will originate (that private key and public key will be managed in the BGP router GUI or CLI). - ICANN will notify all the other BGP routers through the sessions with them about a newly updated such public key of any other BGP router. - ICANN will also receive in real-time any route object creation/modification/deletion notification from any of the 5 RIRs and will then update all the BGP routers through all of their sessions. - In case a BGP router doesn't have an active session to ICANN backend infrastructure (for any reason, might be due to networking issue) - then temporarily the internal 'Check tracking flag' of it will be set to 'off'. After the session with ICANN backend infrastructure will be re-established and the BGP router will receive all the meantime updates - the boolean value of 'Check internal flag' will return to initial state. - Any update from ICANN backend infrastructure to a BGP router (such as a public key of another BGP router, or a routing object update) - will be confirmed that the update was received well by the BGP router side. 'Check tracking flag' in BGP Routers: - BGP routers, in their GUI and CLI interfaces - will not allow the end-user to set the boolean value of 'Check tracking flag', in order to avoid misconfiguration. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - The reason for it, is that if 'Check tracking flag' will be set on some destination BGP routers while some other source BGP routers weren't upgraded yet (and will not send the 'tracking ip packet' due to it) - then 'tracking ip packet' will never reach the destination BGP router and the internet will break. - Central setting of 'Check tracking flag' through ICANN backend infrastructure - will allow ICANN to inform all the BGP routers at once to switch 'on' the 'Check tracking flag' - ICANN, in the session to any BGP router, will also receive the percentage of ip packets that were destained to that BGP router network - that also had ip tracking packets, in this way ICANN will know when all the BGP routers were properly globally updated and when it is time to enable the 'Check tracking flag' in all the BGP routers. - ICANN will know if all the BGP routers in the world were upgraded based on keeping the full BGP table and comparing it to all the BGP routers that did and that did not open a session to ICANN backend infrastructure. Automatic preventation of IoT botnet infections: - IoT botnets are based on default credentials, if we can block default credentials of IoT devices then these kind of botnets (such as Mirai-variants and similar) will stop to have an impact in the internet. - The data field in an ip packet - will always be the same for an access attempt to a IoT device with default credentials - hence these kind of "IP protocol data fingerprints" which are related to specific "IP protocol numbers" will be provided by ICANN backend infrastructure to each BGP router through the opened session with it. - There are two issues with matching incoming ip packets to the "locally stored IP protocol data fingerprints" - the first one is that ip packets can be sent by fragments (so not all the data field will be sent at once in order to be able to be compared with the locally stored data fingerprints) and the second is that usernames (or url's) or any other textual data in the incoming ip packet data field can be in uppercase or in lowercase. In order to overcome the possibility of the existence of a single data fingerprint in multiple incoming ip packet fragments - then in case the BGP router is recognizing the incoming fragmented ip packet data value as part of an existing fingerprint data in its local database then it will keep track of the arrival ip packet fragments based on their specific IP-ID identifier and the BGP router will not forward the last ip packet fragment if the last ip packet fragment will cause all the related ip packet fragments to match a specific ip fingerprint data (last ip packet doesn't have to be the last fragmented part but it is the last ip packet that arrived with that IP-ID identifier, so the BGP router will keep track of the specific fragmented IP packets that arrived and their indexes in order to know when the last one of them arrived). Regarding the second issue - the stored data fingerprints in the local BGP router will be stored in a way that some bytes of them (in specific indexes) will not be compared and in case all the other bytes will match - then the bytes in these indexes - will first be lowered case - and only then comparison will be made to the specific indexed bytes in the specific ip packet data fingerprint. - In case a IoT device behind a BGP router will be infected somehow (for example when a specific fingerprint data with default credentials for a specific device wasn't updated yet through ICANN backend infrastructure), it will be able to infect all the other IoT devices in the local network when the connectivity to them is not through the BGP router, that kind of impact will be much much lower than infected IoT device which can infect any other IoT device in the internet and then massive botnets in the internet are created which are being used for DDoS. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - This problem can be overcome using the following technical addition: the 5 RIR's will operate end-users honeypots machines all over the world (it will be implemented by a single physical machine in each location, for example in each datacenter and in each major ISP, each single physical machine will emulate a virtual router and virtual VM's, the virtual VM's will emulate many different kinds of 'real world machines', any kind of automatic updating (in the operating system configurations) will be disabled, these honeypots machines are not intended to make any outgoing connection, the virtual routers will monitor if any outgoing connection is made and if yes then it is to a botnet C&C, the virtual router will update the ICANN backend infrastructure regarding it and the ICANN backend infrastructure will update all the BGP routers (in their open sessions) regarding it to completely block any communication to that botnet C&C ip address. There will be a web-based system and only the related Law Enforcement Agency of that C&C ip address region - will be able to remove that C&C ip address from being blocked after their manual check. - Honeypot machines will be deployed using 'templates' - these templates must be signed and not anyone can create them, they should be created and signed by an agreed Law Enforcement Agency such as Interpol in order to make sure that these templates are by-design not making any outgoing connection. The templates will be deployed in an automatic way (major ISP's and datacenters will be able to easily add a 'physical honeypot' server in their network, that will be shipped to them), the re-initiation of a compromised 'virtual machine' that made an outgoing connection - will also be automatic through the system in the physical server. Respectfully, Elad

28 51

Re: [members-discuss] [SPAM] Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
by Elad Cohen 01 May '20

01 May '20

I agree with you, let us all keep with the ddos attacks and not resolve them. Respectfully, Elad ________________________________ From: info(a)cowmedia.de Sent: Friday, May 01, 2020 12:27 AM To: Elad Cohen; 'Stuart Willet (primary)'; members-discuss(a)ripe.net Subject: AW: [SPAM] Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, 1st: Again a „technical“ idea from your side that is not thought trough to the end. 2nd: If you will be elected (what i don’t think because of you annoying mostly everyone here) you don’t have the power to do what you expect. Still you need to convince other and still you need to create an RfC an so on, you are not able to convince other because you are rude and don’t accept others oppinions 3rd: because you are rude you also do not have any requirements for the election and we should suggest RIPE to remove you from the list because of missing soft skills 4th: You wrote „bgp routers need to wait for X-number of seconds“. Have you ever thought about what that means with 100 gbit/s devices? 5th: In addition again for mostly every packet you will ask a central service (that again communicates wich means packets are doubled, which result in overflooding of the network. 6th: i don’t want to read any word from you here personally because it just annoyes me. Michael Stenz Von: members-discuss <members-discuss-bounces(a)ripe.net> Im Auftrag von Elad Cohen Gesendet: Donnerstag, 30. April 2020 22:59 An: Stuart Willet (primary) <stu(a)safehosts.co.uk>; members-discuss(a)ripe.net Betreff: [SPAM] Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, The costs will be much much lower than the impacts of the following: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs If you prefer to stay with all the above ok lets stay with it all. If I will be elected you can be sure that I will do everything in my power to implement my solution that will resolve for all of it for all internet users. Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, You are willing to sacrifice the good of the community for a personal attack against me. Regarding what you wrote: do you know how many compute time is wasted for all the current DDoS attacks that this solution will not resolve ? do you know how many costs involved for organizations and companies which are under DDoS attacks ? when you compare the current to the state of this solution then this solution is by far better than the current state. Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In fairness, I couldn’t even be bothered reading further than the worlds BGP routers needing a firmware update to DOUBLE packet count whilst adding compute time at an individual packet level. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn….. From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! I will share the following solution in the near General Meeting and I'm interested to share the following technical solution with you as well, it will completely resolve: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking. And will dramatically lower: IoT botnet infections and Botnet C&Cs. By a single update to any BGP router, not any router needs to be updated, only active BGP routers. If I will have the honor of being elected to the Ripe Board I will harness all the power of Ripe and all of the 5 RIR's and all of the LIR's in the 5 RIR's so routing manufacturing companies will implement the below processes and methods with a single firmware update to their BGP routers. I'm asking for your support in electing me so I will be able to enter the Ripe Board and then I will be able to make everything which is written in this post to come true. Regarding the bgp-anycasted infrastructure written below, ICANN is written but the global bgp-anycasted infrastructure can be managed by the 5 RIR's and/or by the ccTLDs registries (my main point is that who will operate the bgp-anycasted infrastructure is not important for now, as long as it will be an agreed authoritative non-governmental non-commercial global entity/ies) With new tracking protocol over ip, routers will be able to confirm that source ip came from the network of the announcing ASN, and hence spoofed amplification DDoS attacks will be completely annihilated. The Process: At the source BGP router, for any ip packet with a source address that is from the network of the source BGP router (lets call it original ip packet) - the source BGP router will create a new ip packet (lets call it tracking ip packet) with a new transport layer protocol and with the same source address and with the same destination address and with the same IP-ID such as the original ip packet. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router The destination BGP router (a BGP router that the destination address is in its network) whenever it receive a 'tracking ip packet' will check if its have the internal boolean 'Check tracking flag' in it - 'on' or 'off': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it if yes then to drop the tracking ip packet and to forward the related original ip packet to destination but only if the source address is originated from the specific ASN (according to the local ASNs+ranges table in the BGP router, such table will be received from ICANN) If the 'Check tracking flag' is set to 'on' then any original ip packet that arrive to the destination BGP router will wait for the related tracking ip packet (in case the related tracking ip packet didn't already arrived to the destination BGP router). The destination BGP router will manage such waiting for X number of seconds. The destination BGP router will match between a tracking ip packet and an original ip packet - based on their source address and their destination address and their IP-ID which will all be identical. More Aspects: - The end-devices will not need to be updated, any router will not need to be updated, only all the BGP routers will need to be updated. - Any BGP router in the routing path, which the original ip packet and the tracking ip packet are not destined to an ip address in its own network - will not check the content of the tracking ip packet and will forward both the tracking ip packet and the original ip packet as they are. - Each BGP router will have all the public keys (of all the ASN's) locally. - Each BGP router will have a full list of all the ASN's and all the route objects ranges which are related to them locally. How BGP routers will receive all the ranges in all the route objects of all the ASNs (in the 5 RIRs) and all the public keys of all the ASNs (for decrypting the encrypted strings in 'tracking ip packets'): - Each BGP router will create a tcp session with ICANN backend infrastructure (the backend infrastructure of ICANN will use BGP anycast and will be available from many locations worldwide with automatic syncing) - At this stage there will be a handshake process between the BGP router and the ICANN backend infrastructure in order for ICANN to know the correct ASN which is operating the BGP router - the BGP router will send its ASN in cleartext and also its ASN encrypted with its ICANN-communication-private-key , ICANN will know the related public key for the specific ASN from the specific ASN object in the RIR (the public key for communication with ICANN will be displayed there) - after decryption ICANN will compare the decrypted string to the AS Number for successful authentication. - After successful authentication, all the communication will be encrypted, ICANN will notify the BGP router about its public key and ICANN will use the public key of the ASN for the communication with ICANN - from the ASN object in the RIR. - The BGP router will send over the session its public key to be used by other BGP routers in order to decrypt the encrypted string in the tracking ip packets that it will originate (that private key and public key will be managed in the BGP router GUI or CLI). - ICANN will notify all the other BGP routers through the sessions with them about a newly updated such public key of any other BGP router. - ICANN will also receive in real-time any route object creation/modification/deletion notification from any of the 5 RIRs and will then update all the BGP routers through all of their sessions. - In case a BGP router doesn't have an active session to ICANN backend infrastructure (for any reason, might be due to networking issue) - then temporarily the internal 'Check tracking flag' of it will be set to 'off'. After the session with ICANN backend infrastructure will be re-established and the BGP router will receive all the meantime updates - the boolean value of 'Check internal flag' will return to initial state. - Any update from ICANN backend infrastructure to a BGP router (such as a public key of another BGP router, or a routing object update) - will be confirmed that the update was received well by the BGP router side. 'Check tracking flag' in BGP Routers: - BGP routers, in their GUI and CLI interfaces - will not allow the end-user to set the boolean value of 'Check tracking flag', in order to avoid misconfiguration. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - The reason for it, is that if 'Check tracking flag' will be set on some destination BGP routers while some other source BGP routers weren't upgraded yet (and will not send the 'tracking ip packet' due to it) - then 'tracking ip packet' will never reach the destination BGP router and the internet will break. - Central setting of 'Check tracking flag' through ICANN backend infrastructure - will allow ICANN to inform all the BGP routers at once to switch 'on' the 'Check tracking flag' - ICANN, in the session to any BGP router, will also receive the percentage of ip packets that were destained to that BGP router network - that also had ip tracking packets, in this way ICANN will know when all the BGP routers were properly globally updated and when it is time to enable the 'Check tracking flag' in all the BGP routers. - ICANN will know if all the BGP routers in the world were upgraded based on keeping the full BGP table and comparing it to all the BGP routers that did and that did not open a session to ICANN backend infrastructure. Automatic preventation of IoT botnet infections: - IoT botnets are based on default credentials, if we can block default credentials of IoT devices then these kind of botnets (such as Mirai-variants and similar) will stop to have an impact in the internet. - The data field in an ip packet - will always be the same for an access attempt to a IoT device with default credentials - hence these kind of "IP protocol data fingerprints" which are related to specific "IP protocol numbers" will be provided by ICANN backend infrastructure to each BGP router through the opened session with it. - There are two issues with matching incoming ip packets to the "locally stored IP protocol data fingerprints" - the first one is that ip packets can be sent by fragments (so not all the data field will be sent at once in order to be able to be compared with the locally stored data fingerprints) and the second is that usernames (or url's) or any other textual data in the incoming ip packet data field can be in uppercase or in lowercase. In order to overcome the possibility of the existence of a single data fingerprint in multiple incoming ip packet fragments - then in case the BGP router is recognizing the incoming fragmented ip packet data value as part of an existing fingerprint data in its local database then it will keep track of the arrival ip packet fragments based on their specific IP-ID identifier and the BGP router will not forward the last ip packet fragment if the last ip packet fragment will cause all the related ip packet fragments to match a specific ip fingerprint data (last ip packet doesn't have to be the last fragmented part but it is the last ip packet that arrived with that IP-ID identifier, so the BGP router will keep track of the specific fragmented IP packets that arrived and their indexes in order to know when the last one of them arrived). Regarding the second issue - the stored data fingerprints in the local BGP router will be stored in a way that some bytes of them (in specific indexes) will not be compared and in case all the other bytes will match - then the bytes in these indexes - will first be lowered case - and only then comparison will be made to the specific indexed bytes in the specific ip packet data fingerprint. - In case a IoT device behind a BGP router will be infected somehow (for example when a specific fingerprint data with default credentials for a specific device wasn't updated yet through ICANN backend infrastructure), it will be able to infect all the other IoT devices in the local network when the connectivity to them is not through the BGP router, that kind of impact will be much much lower than infected IoT device which can infect any other IoT device in the internet and then massive botnets in the internet are created which are being used for DDoS. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - This problem can be overcome using the following technical addition: the 5 RIR's will operate end-users honeypots machines all over the world (it will be implemented by a single physical machine in each location, for example in each datacenter and in each major ISP, each single physical machine will emulate a virtual router and virtual VM's, the virtual VM's will emulate many different kinds of 'real world machines', any kind of automatic updating (in the operating system configurations) will be disabled, these honeypots machines are not intended to make any outgoing connection, the virtual routers will monitor if any outgoing connection is made and if yes then it is to a botnet C&C, the virtual router will update the ICANN backend infrastructure regarding it and the ICANN backend infrastructure will update all the BGP routers (in their open sessions) regarding it to completely block any communication to that botnet C&C ip address. There will be a web-based system and only the related Law Enforcement Agency of that C&C ip address region - will be able to remove that C&C ip address from being blocked after their manual check. - Honeypot machines will be deployed using 'templates' - these templates must be signed and not anyone can create them, they should be created and signed by an agreed Law Enforcement Agency such as Interpol in order to make sure that these templates are by-design not making any outgoing connection. The templates will be deployed in an automatic way (major ISP's and datacenters will be able to easily add a 'physical honeypot' server in their network, that will be shipped to them), the re-initiation of a compromised 'virtual machine' that made an outgoing connection - will also be automatic through the system in the physical server. Respectfully, Elad

3 6

Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
by Elad Cohen 01 May '20

01 May '20

Gert, Let me summarize what you just wrote: "I'm so afraid and I'm a big big coward that IPv4+ will be implemented and then I will have less work with my IPv6 and the deployment of IPv6 will be slower and then the community will earn more 4,294,967,296 IPv4+ addresses but who cares because I like this state that companies must switch to IPv6 and we can overcharge them" Did I got it right ? Respectfully, Elad ________________________________ From: Gert Doering Sent: Friday, May 01, 2020 12:21 AM To: Elad Cohen Cc: members-discuss(a)ripe.net Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hi, On Thu, Apr 30, 2020 at 08:30:48PM +0000, Elad Cohen wrote: > I'm asking for your support in electing me so I will be able to enter the Ripe Board and then I will be able to make everything which is written in this post to come true. "Vote for me, and you shall have bread and circuses - and if not, you will have to stay miserable forever!" Am I summarizing this correctly? (This approach worked brilliantly in the past, but in the long run, the roman empire fell...) Gert Doering -- NetMaster -- 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

2 1

Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
by Elad Cohen 01 May '20

01 May '20

Both of you supporting another candidate and that is perfectly fine, you can just say it clearly. We can keep being with DDoS attacks if you wish. Respectfully, Elad ________________________________ From: Tulp Solutions (O. Verheijen) <o.verheijen(a)tulpsolutions.com> Sent: Friday, May 1, 2020 12:27 AM To: Elad Cohen <elad(a)netstyle.io> Cc: Stuart Willet (primary) <stu(a)safehosts.co.uk>; members-discuss(a)ripe.net <members-discuss(a)ripe.net> Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please stop! There were no personal attacks, just different opinions. We clearly have a different opinion on what qualities one should have to get elected board member, but that's just fine, I don't feel attacked or offended by you. 'much much lower' is not a number, it does not work for me, especially when the only real requirement is that we should elect you first... @Stuart, is that sweet or salty popcorn you have there? Regards, Olof Op do 30 apr. 2020 om 22:59 schreef Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>: Stuart, The costs will be much much lower than the impacts of the following: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs If you prefer to stay with all the above ok lets stay with it all. If I will be elected you can be sure that I will do everything in my power to implement my solution that will resolve for all of it for all internet users. Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io<mailto:elad@netstyle.io>] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, You are willing to sacrifice the good of the community for a personal attack against me. Regarding what you wrote: do you know how many compute time is wasted for all the current DDoS attacks that this solution will not resolve ? do you know how many costs involved for organizations and companies which are under DDoS attacks ? when you compare the current to the state of this solution then this solution is by far better than the current state. Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In fairness, I couldn’t even be bothered reading further than the worlds BGP routers needing a firmware update to DOUBLE packet count whilst adding compute time at an individual packet level. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn….. From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! I will share the following solution in the near General Meeting and I'm interested to share the following technical solution with you as well, it will completely resolve: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking. And will dramatically lower: IoT botnet infections and Botnet C&Cs. By a single update to any BGP router, not any router needs to be updated, only active BGP routers. If I will have the honor of being elected to the Ripe Board I will harness all the power of Ripe and all of the 5 RIR's and all of the LIR's in the 5 RIR's so routing manufacturing companies will implement the below processes and methods with a single firmware update to their BGP routers. I'm asking for your support in electing me so I will be able to enter the Ripe Board and then I will be able to make everything which is written in this post to come true. Regarding the bgp-anycasted infrastructure written below, ICANN is written but the global bgp-anycasted infrastructure can be managed by the 5 RIR's and/or by the ccTLDs registries (my main point is that who will operate the bgp-anycasted infrastructure is not important for now, as long as it will be an agreed authoritative non-governmental non-commercial global entity/ies) With new tracking protocol over ip, routers will be able to confirm that source ip came from the network of the announcing ASN, and hence spoofed amplification DDoS attacks will be completely annihilated. The Process: At the source BGP router, for any ip packet with a source address that is from the network of the source BGP router (lets call it original ip packet) - the source BGP router will create a new ip packet (lets call it tracking ip packet) with a new transport layer protocol and with the same source address and with the same destination address and with the same IP-ID such as the original ip packet. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router The destination BGP router (a BGP router that the destination address is in its network) whenever it receive a 'tracking ip packet' will check if its have the internal boolean 'Check tracking flag' in it - 'on' or 'off': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it if yes then to drop the tracking ip packet and to forward the related original ip packet to destination but only if the source address is originated from the specific ASN (according to the local ASNs+ranges table in the BGP router, such table will be received from ICANN) If the 'Check tracking flag' is set to 'on' then any original ip packet that arrive to the destination BGP router will wait for the related tracking ip packet (in case the related tracking ip packet didn't already arrived to the destination BGP router). The destination BGP router will manage such waiting for X number of seconds. The destination BGP router will match between a tracking ip packet and an original ip packet - based on their source address and their destination address and their IP-ID which will all be identical. More Aspects: - The end-devices will not need to be updated, any router will not need to be updated, only all the BGP routers will need to be updated. - Any BGP router in the routing path, which the original ip packet and the tracking ip packet are not destined to an ip address in its own network - will not check the content of the tracking ip packet and will forward both the tracking ip packet and the original ip packet as they are. - Each BGP router will have all the public keys (of all the ASN's) locally. - Each BGP router will have a full list of all the ASN's and all the route objects ranges which are related to them locally. How BGP routers will receive all the ranges in all the route objects of all the ASNs (in the 5 RIRs) and all the public keys of all the ASNs (for decrypting the encrypted strings in 'tracking ip packets'): - Each BGP router will create a tcp session with ICANN backend infrastructure (the backend infrastructure of ICANN will use BGP anycast and will be available from many locations worldwide with automatic syncing) - At this stage there will be a handshake process between the BGP router and the ICANN backend infrastructure in order for ICANN to know the correct ASN which is operating the BGP router - the BGP router will send its ASN in cleartext and also its ASN encrypted with its ICANN-communication-private-key , ICANN will know the related public key for the specific ASN from the specific ASN object in the RIR (the public key for communication with ICANN will be displayed there) - after decryption ICANN will compare the decrypted string to the AS Number for successful authentication. - After successful authentication, all the communication will be encrypted, ICANN will notify the BGP router about its public key and ICANN will use the public key of the ASN for the communication with ICANN - from the ASN object in the RIR. - The BGP router will send over the session its public key to be used by other BGP routers in order to decrypt the encrypted string in the tracking ip packets that it will originate (that private key and public key will be managed in the BGP router GUI or CLI). - ICANN will notify all the other BGP routers through the sessions with them about a newly updated such public key of any other BGP router. - ICANN will also receive in real-time any route object creation/modification/deletion notification from any of the 5 RIRs and will then update all the BGP routers through all of their sessions. - In case a BGP router doesn't have an active session to ICANN backend infrastructure (for any reason, might be due to networking issue) - then temporarily the internal 'Check tracking flag' of it will be set to 'off'. After the session with ICANN backend infrastructure will be re-established and the BGP router will receive all the meantime updates - the boolean value of 'Check internal flag' will return to initial state. - Any update from ICANN backend infrastructure to a BGP router (such as a public key of another BGP router, or a routing object update) - will be confirmed that the update was received well by the BGP router side. 'Check tracking flag' in BGP Routers: - BGP routers, in their GUI and CLI interfaces - will not allow the end-user to set the boolean value of 'Check tracking flag', in order to avoid misconfiguration. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - The reason for it, is that if 'Check tracking flag' will be set on some destination BGP routers while some other source BGP routers weren't upgraded yet (and will not send the 'tracking ip packet' due to it) - then 'tracking ip packet' will never reach the destination BGP router and the internet will break. - Central setting of 'Check tracking flag' through ICANN backend infrastructure - will allow ICANN to inform all the BGP routers at once to switch 'on' the 'Check tracking flag' - ICANN, in the session to any BGP router, will also receive the percentage of ip packets that were destained to that BGP router network - that also had ip tracking packets, in this way ICANN will know when all the BGP routers were properly globally updated and when it is time to enable the 'Check tracking flag' in all the BGP routers. - ICANN will know if all the BGP routers in the world were upgraded based on keeping the full BGP table and comparing it to all the BGP routers that did and that did not open a session to ICANN backend infrastructure. Automatic preventation of IoT botnet infections: - IoT botnets are based on default credentials, if we can block default credentials of IoT devices then these kind of botnets (such as Mirai-variants and similar) will stop to have an impact in the internet. - The data field in an ip packet - will always be the same for an access attempt to a IoT device with default credentials - hence these kind of "IP protocol data fingerprints" which are related to specific "IP protocol numbers" will be provided by ICANN backend infrastructure to each BGP router through the opened session with it. - There are two issues with matching incoming ip packets to the "locally stored IP protocol data fingerprints" - the first one is that ip packets can be sent by fragments (so not all the data field will be sent at once in order to be able to be compared with the locally stored data fingerprints) and the second is that usernames (or url's) or any other textual data in the incoming ip packet data field can be in uppercase or in lowercase. In order to overcome the possibility of the existence of a single data fingerprint in multiple incoming ip packet fragments - then in case the BGP router is recognizing the incoming fragmented ip packet data value as part of an existing fingerprint data in its local database then it will keep track of the arrival ip packet fragments based on their specific IP-ID identifier and the BGP router will not forward the last ip packet fragment if the last ip packet fragment will cause all the related ip packet fragments to match a specific ip fingerprint data (last ip packet doesn't have to be the last fragmented part but it is the last ip packet that arrived with that IP-ID identifier, so the BGP router will keep track of the specific fragmented IP packets that arrived and their indexes in order to know when the last one of them arrived). Regarding the second issue - the stored data fingerprints in the local BGP router will be stored in a way that some bytes of them (in specific indexes) will not be compared and in case all the other bytes will match - then the bytes in these indexes - will first be lowered case - and only then comparison will be made to the specific indexed bytes in the specific ip packet data fingerprint. - In case a IoT device behind a BGP router will be infected somehow (for example when a specific fingerprint data with default credentials for a specific device wasn't updated yet through ICANN backend infrastructure), it will be able to infect all the other IoT devices in the local network when the connectivity to them is not through the BGP router, that kind of impact will be much much lower than infected IoT device which can infect any other IoT device in the internet and then massive botnets in the internet are created which are being used for DDoS. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - This problem can be overcome using the following technical addition: the 5 RIR's will operate end-users honeypots machines all over the world (it will be implemented by a single physical machine in each location, for example in each datacenter and in each major ISP, each single physical machine will emulate a virtual router and virtual VM's, the virtual VM's will emulate many different kinds of 'real world machines', any kind of automatic updating (in the operating system configurations) will be disabled, these honeypots machines are not intended to make any outgoing connection, the virtual routers will monitor if any outgoing connection is made and if yes then it is to a botnet C&C, the virtual router will update the ICANN backend infrastructure regarding it and the ICANN backend infrastructure will update all the BGP routers (in their open sessions) regarding it to completely block any communication to that botnet C&C ip address. There will be a web-based system and only the related Law Enforcement Agency of that C&C ip address region - will be able to remove that C&C ip address from being blocked after their manual check. - Honeypot machines will be deployed using 'templates' - these templates must be signed and not anyone can create them, they should be created and signed by an agreed Law Enforcement Agency such as Interpol in order to make sure that these templates are by-design not making any outgoing connection. The templates will be deployed in an automatic way (major ISP's and datacenters will be able to easily add a 'physical honeypot' server in their network, that will be shipped to them), the re-initiation of a compromised 'virtual machine' that made an outgoing connection - will also be automatic through the system in the physical server. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/olof%40tulpsolutions…

3 4

Fw: You have my vote!
by Elad Cohen 30 Apr '20

30 Apr '20

Thank you Gabriel. Respectfully, Elad ________________________________________ From: Gabriel VOITIS <voitis(a)infinitytelecom.ro> Sent: Thursday, April 30, 2020 11:42 PM To: Elad Cohen Subject: You have my vote! -- Sent from mobile Mulțumesc, Gabriel VOITIS

1 0

UNSUBSCRIBE
by David Simmons 27 Apr '20

27 Apr '20

UNSUBSCRIBE

13 12

ban4flood
by Christian Rodler 27 Apr '20

27 Apr '20

Before most of us unsubscribe from this list: Would be nice if the "responsible" of this mailing list could find a way to ban a member for lets say one week if >x% of subscibers complain about (off-topics- coconuts or whatever). I never thought membes-discuss mailing list == Kindergarden Best regards, Christian Rodler -- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus

2 1

Re: [members-discuss] Regarding Elad Cohen's nomination and emails
by Elad Cohen 27 Apr '20

27 Apr '20

Ed is lying, I'm not harassing him or anyone else off the list, Ed is the one keep emailing me directly when I asked him to stop doing it. Respectfully, Elad ________________________________ From: Ed Campbell Sent: Monday, April 27, 2020 4:47 PM To: Elad Cohen Cc: Chris Lawrence; Cynthia Revström; members-discuss(a)ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails All, This guy doesn’t know how to shut up. I would not normally do this but he is harassing me directly “off-list” and “off-topic”. The unprofessional approach he has taken to his responses should be enough to turn anyone away from him but he is now harassing me when asked not to. I have made an official complaint against him and will let the NCC deal with him. Kind regards, Ed On 27 Apr 2020, at 14:43, Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> wrote: Chris, This wasn't my conversation, this was my response to an attack on me. Take your fake messages off the list. Respectfully, Elad ________________________________ From: Chris Lawrence <chris.lawrence(a)nomical.com<mailto:chris.lawrence@nomical.com>> Sent: Monday, April 27, 2020 3:44 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad Enough now this is beyond a joke.. Please take your conversations off the list. Regards Chris Chris Lawrence Senior Solutions Architect +44 344 384 3000<tel:+44%20344%20384%203000> +44 7775 871094<tel:+44%207775%20871094> nomical.com<http://nomical.com/> Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE This email and any attachments are intended for the named recipient only. Its unauthorised use, distribution, disclosure, storage or copying is not permitted. If you have received it in error, please destroy all copies and notify the sender. In messages of a non-business nature, the views and opinions expressed are the author's own and do not necessarily reflect those of the organisation from which it is sent. All emails may be subject to monitoring. Nomical Ltd - Registered in England No: 06035958, VAT Reg No: 900363074, Registered Office: Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE From: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> on behalf of Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Date: Monday, 27 April 2020 at 13:43 To: Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>>, "members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>" <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails This is amazing how the illegal anonymous "The Spamhaus Project" members keep twisting the facts. Cynthia, Zero evidence was provided, not even a single proof, but still you claim "lots of evidence" I didn't say that anyone is part of "The Spamhaus Project" because disagree with me, I said that anyone is part of the illegal anonymous organization "The Spamhaus Project" because he is part of the illegal anonymous organization "The Spamhaus Project" - see how much you are personally targeting me - see how much you are protecting your sick friend RFG. Please don't interpret me - coconut means coconut - RFG is a coconut by anyone that knows him personally. Here is what your sick friend wrote: https://imgur.com/AcmgwEX (his opinion on all Dutch people as a whole - "Dutch are any more inclined toward cybercrime") https://imgur.com/WUZvdNJ (his opinion on all Colombian Network Operators usage of the internet as a whole - "Undoubtedly drug smuggling over HTTP") https://imgur.com/a/1ULfVEC (his opinion on the City of Chicago including all of its citizens as a whole - "American city most known for its high ideals and consistantely ethical behavior, Chicago") https://imgur.com/AQCmZlk (RFG being identified as racist in Nanog) https://imgur.com/a/Rzrbxkz (RFG being identified as antisemitic in Nanog) RFG called me in two names that one of them you wrote, you can keep with your lies and to defend a racist and an antisemitic person - but there is something which is called context, you can see in the first link above that RFG quoted Shakespeare regarding the Netherlands, when he called me in the name that you mentioned he did it after not providing not even a single proof against me and he specially used that name - which also in Shakespeare being referred to jews - you are defending a person which is a racist and an antisemitic according to all the above links. Respectfully, Elad ________________________________ From: Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>> Sent: Monday, April 27, 2020 2:50 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hi Elad, There are 3 major differences I see here, 1. rfg presents lots of evidence that you would have been involved in shady things (I am not sure if they are true and frankly I don't have time currently to look at all of the documents) Meanwhile you are saying that people are part of "The illegal anonymous Spamhaus Project" just because they disagree with you, and as you have said that I am involved in Spamhaus, I would like for you to give me any proof that I am involved with spamhaus in any way (which I am not). 2. rfg called you a "crook", which means dishonest or illegal, which would be true if the things rfg stated are in fact true. Meanwhile you called rfg a "coconut" which can't be anything other than an insult referring to you thinking he is dumb. 3. rfg called you a "crook" once in a long email after describing why he thinks you are a "crook", meanwhile you sent an email that I have posted in its entirety below. > START Michael, Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. Respectfully, Elad > END Please just stop it Elad. Now I still think it was wrong of rfg to use that word, but it is not at all the same thing in my eyes. - Cynthia On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> wrote: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301… These are all complete lies only because I found out who are the real people behind "The Spamhaus Project" You can see how he is calling me there Everything there are lies and fake, the "source" for the fake media report is a member of "The Spamhaus Project" and also an employee of a direct competitor (that enjoyed from that fake media report) of a company which used the netblock, and the "source" is also the owner of that criminal twitter account:https://twitter.com/UnderTheBreach , he is a master of cyber influence operations according to his own words in his criminal twitter account and also a member of your cyber-security community. Respectfully, Elad ________________________________ From: Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>> Sent: Monday, April 27, 2020 2:14 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, please send me an archive link to the specific email on a RIPE/RIPE NCC mailing list where RFG called you a rude name. - Cynthia On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> wrote: He called me with antisemitic names many times and on many working groups and you said nothing, you claim not to see his messages, but you clearly saw all of my messages and you are monitoring me pretty well. I'm sorry but I don't believe you, specially when you are attacking me personally so heavily with distorting the facts. You clearly so the word coconut - so you also saw what I shared on the same post that he wrote on other groups of people and that he was called a racist and an antisemitic - but you decided to ignore this as well, so you didn't read my whole post - you read only the word 'coconut' and you decided to jump in ? Cynthia, please spread your lies somewhere else. Respectfully, Elad ________________________________ From: Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>> Sent: Monday, April 27, 2020 2:05 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, first of all, I am not an employee or in any way related to Spamhaus, and I doubt many of the people you have suggested are part of it have anything to do with it either. And because I have things to do that are not spending my entire days on RIPE mailing lists I guess I missed RFG calling you names, but I will assure you that if I was on those discussions I would call him out if he called you a "coconut" or similar. Also just because someone has called you names on mailing lists doesn't mean you get to call them names on mailing lists. - Cynthia On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> wrote: Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> on behalf of Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>> Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] <ripe-md(a)c4inet.net<mailto:ripe-md@c4inet.net>> Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] <ripe-md(a)c4inet.net<mailto:ripe-md@c4inet.net>> wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie

2 1

Re: [members-discuss] Regarding Elad Cohen's nomination and emails
by Cynthia Revström 27 Apr '20

27 Apr '20

Hi Elad, There are 3 major differences I see here, 1. rfg presents lots of evidence that you would have been involved in shady things (I am not sure if they are true and frankly I don't have time currently to look at all of the documents) Meanwhile you are saying that people are part of "The illegal anonymous Spamhaus Project" just because they disagree with you, and as you have said that I am involved in Spamhaus, I would like for you to give me any proof that I am involved with spamhaus in any way (which I am not). 2. rfg called you a "crook", which means dishonest or illegal, which would be true if the things rfg stated are in fact true. Meanwhile you called rfg a "coconut" which can't be anything other than an insult referring to you thinking he is dumb. 3. rfg called you a "crook" once in a long email after describing why he thinks you are a "crook", meanwhile you sent an email that I have posted in its entirety below. > START Michael, Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. Respectfully, Elad > END Please just stop it Elad. Now I still think it was wrong of rfg to use that word, but it is not at all the same thing in my eyes. - Cynthia On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen <elad(a)netstyle.io> wrote: > > https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301… > > These are all complete lies only because I found out who are the real > people behind "The Spamhaus Project" > > You can see how he is calling me there > > Everything there are lies and fake, the "source" for the fake media report > is a member of "The Spamhaus Project" and also an employee of a direct > competitor (that enjoyed from that fake media report) of a company which > used the netblock, and the "source" is also the owner of that criminal > twitter account: https://twitter.com/UnderTheBreach , he is a master of > cyber influence operations according to his own words in his criminal > twitter account and also a member of your cyber-security community. > > Respectfully, > Elad > ------------------------------ > *From:* Cynthia Revström <me(a)cynthia.re> > *Sent:* Monday, April 27, 2020 2:14 PM > *To:* Elad Cohen <elad(a)netstyle.io> > *Cc:* members-discuss(a)ripe.net <members-discuss(a)ripe.net> > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and > emails > > Elad, please send me an archive link to the specific email on a RIPE/RIPE > NCC mailing list where RFG called you a rude name. > > - Cynthia > > On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen <elad(a)netstyle.io> wrote: > > He called me with antisemitic names many times and on many working groups > and you said nothing, you claim not to see his messages, but you clearly > saw all of my messages and you are monitoring me pretty well. I'm sorry but > I don't believe you, specially when you are attacking me personally so > heavily with distorting the facts. You clearly so the word coconut - so you > also saw what I shared on the same post that he wrote on other groups of > people and that he was called a racist and an antisemitic - but you decided > to ignore this as well, so you didn't read my whole post - you read only > the word 'coconut' and you decided to jump in ? > > Cynthia, please spread your lies somewhere else. > > Respectfully, > Elad > ------------------------------ > *From:* Cynthia Revström <me(a)cynthia.re> > *Sent:* Monday, April 27, 2020 2:05 PM > *To:* Elad Cohen <elad(a)netstyle.io> > *Cc:* members-discuss(a)ripe.net <members-discuss(a)ripe.net> > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and > emails > > Elad, first of all, I am not an employee or in any way related to > Spamhaus, and I doubt many of the people you have suggested are part of it > have anything to do with it either. > > And because I have things to do that are not spending my entire days on > RIPE mailing lists I guess I missed RFG calling you names, but I will > assure you that if I was on those discussions I would call him out if he > called you a "coconut" or similar. > Also just because someone has called you names on mailing lists doesn't > mean you get to call them names on mailing lists. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen <elad(a)netstyle.io> wrote: > > Cynthia, > > The sick person which you are referring to and is your colleague from "The > Spamhaus Project", defamed me for many many months, here in Ripe and in > Nanog, he called me by many names without a single proof. He was called an > antisemitic and a racist not by me - but by people which are not related > to me in Nanog. After many months I provided an official response in Ripe. > I didn't hear your voice when he defamed me for many many months with him > calling me by many names. So obviously your interests are hidden. > > In the other working groups - I only replied to him, and I didn't hear > your voice regarding your sick colleague initial message with name callings > towards me when I only replied to his attack on me. And his personal attack > on me is exactly like your personal attack on me now - you are afraid that > an alternative solution to "The Spamhaus Project" will be implemented if I > will be elected. > > Respectfully, > Elad > ------------------------------ > *From:* members-discuss <members-discuss-bounces(a)ripe.net> on behalf of > Cynthia Revström <me(a)cynthia.re> > *Sent:* Monday, April 27, 2020 1:50 PM > *To:* Sascha Luck [ml] <ripe-md(a)c4inet.net> > *Cc:* members-discuss(a)ripe.net <members-discuss(a)ripe.net> > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and > emails > > > The RIPE *NCC* has no business either enforcing "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. > > AFAIK there are no WG chairs of members-discuss and members-discuss is a > mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE > NCC membership related topics, so I think they certainly have business > enforcing people to be professional on this mailing list. > > I would also like to add that Elad has multiple times on different mailing > lists ignored the WG chairs. > Also this is happening across a variety of RIPE/RIPE NCC mailing lists > that are all hosted by the RIPE NCC and as such I think it is their > business to keep them to a professional standard. > > > If I'm wrong, where do > I submit the list of people I'd like to see excluded from the > community? > > There should not be a long list of people, but when someone is behaving > unprofessionally, calling people "coconut", being defamatory towards the > RIPE NCC, ignoring WG chairs, I do think that they have gone too far and > everything has a limit. > Like we wouldn't allow someone to send sales emails to the mailing list as > an example, aka limits on what is allowed. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] <ripe-md(a)c4inet.net> > wrote: > > On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: > >I would like to propose that the RIPE NCC ban Elad Cohen from interacting > >with the RIPE Community (via Meetings or mailing lists) due to his blatant > >disregard for the Code of Conduct and for being hostile towards others in > >the community. As the RIPE NCC hosts and manages these lists I think the > >RIPE NCC has a responsibility to keep the lists professional and to remove > >those who repeatedly ignore what the WG chairs are saying. > > The RIPE *NCC* has no business either enforcing "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. Nor do I think the NCC should determine who can > be a member of the RIPE community or not. If I'm wrong, where do > I submit the list of people I'd like to see excluded from the > community? > I think this proposal is the most out-of-order thing I've yet > seen in this thread. > > rgds, > Sascha Luck > > > > >- Cynthia > > >_______________________________________________ > >members-discuss mailing list > >members-discuss(a)ripe.net > >https://lists.ripe.net/mailman/listinfo/members-discuss > >Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net > > > _______________________________________________ > members-discuss mailing list > members-discuss(a)ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re > >

8 8