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
Let the fun begin again!!! On Fri, 1 May 2020 at 00:31 Elad Cohen <elad@netstyle.io> wrote:
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@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/munir%40aeserver.com
-- <https://www.aeserver.com/> *MUNIR BADR* Book A Call: Click here <https://calendly.com/aeserver/call/> Sales Hotline: *800 123 123* | Intl: +971 4 2493030 <https://www.facebook.com/AEserver/> <https://twitter.com/aeserver> <https://www.instagram.com/aeserver/> <https://www.linkedin.com/company/aeserver/>
Is there a way to unsubscribe from individual topics? I don't want to be part of this fun...
I would love to use this feature as well.
Is there a way to unsubscribe from individual topics? I don't want to be part of this fun...
PSA for Google Mail users who do not want to be part of this conversation: there's a per-thread "mute" feature in the top-level menu. Am Do., 30. Apr. 2020 um 22:40 Uhr schrieb Bora Ismen < bora.ismen@nimbevo.com>:
Is there a way to unsubscribe from individual topics? I don't want to be part of this fun...
_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/mail%40leoschabel.de
Hi Elad, Do you really know how AnyCast work? It's not a silver bullet to solve these problems. Stop it. Get some help :-) https://www.youtube.com/watch?v=l60MnDJklnM On Fri, May 1, 2020 at 5:35 AM Leopold Schabel <mail@leoschabel.de> wrote:
PSA for Google Mail users who do not want to be part of this conversation: there's a per-thread "mute" feature in the top-level menu.
Am Do., 30. Apr. 2020 um 22:40 Uhr schrieb Bora Ismen < bora.ismen@nimbevo.com>:
Is there a way to unsubscribe from individual topics? I don't want to be part of this fun...
_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/mail%40leoschabel.de
_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aveline%40misaka.io
Please people at RIPE, kick this man off the list. This is not the place for rfc’s as numerously told to him. How many more people have to unsubscribe first. And my apologies to the rest of you as being part of the problem. Regards, Oscar Wieman Verstuurd vanaf mijn iPhone Op 30 apr. 2020 om 22:35 heeft Munir Badr <munir@aeserver.com> het volgende geschreven: Let the fun begin again!!! On Fri, 1 May 2020 at 00:31 Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>> wrote: 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@ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/munir%40aeserver.com -- [https://i.ibb.co/RQQ6140/logo-aeserver-final.png]<https://www.aeserver.com/> MUNIR BADR Book A Call: Click here<https://calendly.com/aeserver/call/> Sales Hotline: 800 123 123 | Intl: +971 4 2493030 [https://i.ibb.co/X87cNSW/facebook.png]<https://www.facebook.com/AEserver/> [https://i.ibb.co/PtLjz7w/twitter.png] <https://twitter.com/aeserver> [https://i.ibb.co/XY0qPKH/instagram.png] <https://www.instagram.com/aeserver/> [https://i.ibb.co/RQNVxch/linkedin.png] <https://www.linkedin.com/company/aeserver/> _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/oscar.wieman%40mybit....
Oscar is just supporting another candidate, which is afraid of me being elected, that is all. Respectfully, Ekad ________________________________ From: Oscar Wieman <oscar.wieman@MyBit.nl> Sent: Thursday, April 30, 2020 11:43 PM To: Munir Badr <munir@aeserver.com> Cc: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <members-discuss@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 Please people at RIPE, kick this man off the list. This is not the place for rfc’s as numerously told to him. How many more people have to unsubscribe first. And my apologies to the rest of you as being part of the problem. Regards, Oscar Wieman Verstuurd vanaf mijn iPhone Op 30 apr. 2020 om 22:35 heeft Munir Badr <munir@aeserver.com> het volgende geschreven: Let the fun begin again!!! On Fri, 1 May 2020 at 00:31 Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>> wrote: 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@ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/munir%40aeserver.com -- [https://i.ibb.co/RQQ6140/logo-aeserver-final.png]<https://www.aeserver.com/> MUNIR BADR Book A Call: Click here<https://calendly.com/aeserver/call/> Sales Hotline: 800 123 123 | Intl: +971 4 2493030 [https://i.ibb.co/X87cNSW/facebook.png]<https://www.facebook.com/AEserver/> [https://i.ibb.co/PtLjz7w/twitter.png] <https://twitter.com/aeserver> [https://i.ibb.co/XY0qPKH/instagram.png] <https://www.instagram.com/aeserver/> [https://i.ibb.co/RQNVxch/linkedin.png] <https://www.linkedin.com/company/aeserver/> _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/oscar.wieman%40mybit....
Hi Ekad, The only thing I have against you is my annoyance the past week of you making conspiracy theories and trying to push your stupid bullshit on all the people on this list. Enough is enough. Verstuurd vanaf mijn iPhone Op 30 apr. 2020 om 22:44 heeft Elad Cohen <elad@netstyle.io> het volgende geschreven: Oscar is just supporting another candidate, which is afraid of me being elected, that is all. Respectfully, Ekad ________________________________ From: Oscar Wieman <oscar.wieman@MyBit.nl> Sent: Thursday, April 30, 2020 11:43 PM To: Munir Badr <munir@aeserver.com> Cc: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <members-discuss@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 Please people at RIPE, kick this man off the list. This is not the place for rfc’s as numerously told to him. How many more people have to unsubscribe first. And my apologies to the rest of you as being part of the problem. Regards, Oscar Wieman Verstuurd vanaf mijn iPhone Op 30 apr. 2020 om 22:35 heeft Munir Badr <munir@aeserver.com> het volgende geschreven: Let the fun begin again!!! On Fri, 1 May 2020 at 00:31 Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>> wrote: 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@ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/munir%40aeserver.com -- [https://i.ibb.co/RQQ6140/logo-aeserver-final.png]<https://www.aeserver.com/> MUNIR BADR Book A Call: Click here<https://calendly.com/aeserver/call/> Sales Hotline: 800 123 123 | Intl: +971 4 2493030 [https://i.ibb.co/X87cNSW/facebook.png]<https://www.facebook.com/AEserver/> [https://i.ibb.co/PtLjz7w/twitter.png] <https://twitter.com/aeserver> [https://i.ibb.co/XY0qPKH/instagram.png] <https://www.instagram.com/aeserver/> [https://i.ibb.co/RQNVxch/linkedin.png] <https://www.linkedin.com/company/aeserver/> _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/oscar.wieman%40mybit....
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@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
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@safehosts.co.uk> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <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@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
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@safehosts.co.uk>; 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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@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
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@safehosts.co.uk> Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <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@safehosts.co.uk>; 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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@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
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@safehosts.co.uk>; 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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@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
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@safehosts.co.uk> Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <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@safehosts.co.uk>; 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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@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
Elad, As repeatedly explained to you, it simply is not possible to go around updating EVERY piece of hardware and software used for BGP sessions. I don't know why you can't comprehend this, so I am simply going to stop responding to you. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 30 April 2020 21:59 To: Stuart Willet (primary) <stu@safehosts.co.uk>; 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, 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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@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
Stuart, All the bgp routers will be upgraded if I will be elected, you can be sure of it, including EOL routers, there is and there will be solution for anything. After it all internet users will enjoy from the end of: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking And the dramatically reducing of: IoT botnet infections and Botnet C&Cs Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu@safehosts.co.uk> Sent: Friday, May 1, 2020 12:01 AM To: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <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, As repeatedly explained to you, it simply is not possible to go around updating EVERY piece of hardware and software used for BGP sessions. I don’t know why you can’t comprehend this, so I am simply going to stop responding to you. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 30 April 2020 21:59 To: Stuart Willet (primary) <stu@safehosts.co.uk>; 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, 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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@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
Elad, Can you explain why implementing uRPF (https://en.wikipedia.org/wiki/Reverse-path_forwarding#Unicast_RPF) as part of BCP38 would not work? It's a simple knob to enable on an interface of the post popular routing vendors and *NIX distributions, it's been around forever, it doesn't require the use of any routing protocol, or a central authority. Thanks, Ryan Hamel Network Support Engineer W: www.essensys.tech The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately by reply. essensys plc is a registered, public company in England and Wales. Registered Office: Aldgate Tower, Leman Street, London, E1 8FA essensys Inc is a Delaware company. Registered Office: 450 7th Avenue, New York, NY 10123 From: members-discuss <members-discuss-bounces@ripe.net> On Behalf Of Elad Cohen Sent: Thursday, April 30, 2020 2:05 PM To: Stuart Willet (primary) <stu@safehosts.co.uk>; members-discuss@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 Stuart, All the bgp routers will be upgraded if I will be elected, you can be sure of it, including EOL routers, there is and there will be solution for anything. After it all internet users will enjoy from the end of: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking And the dramatically reducing of: IoT botnet infections and Botnet C&Cs Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Friday, May 1, 2020 12:01 AM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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, As repeatedly explained to you, it simply is not possible to go around updating EVERY piece of hardware and software used for BGP sessions. I don't know why you can't comprehend this, so I am simply going to stop responding to you. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 30 April 2020 21:59 To: Stuart Willet (primary) <stu@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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, 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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@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 Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
"All the bgp routers will be upgraded if I will be elected, you can be sure of it, including EOL routers, there is and there will be solution for anything." ROFLMAO! Can we have immortality with infinite money as well on the go? :) Or is this the type of promise where RIPE membership annual fee balloons by approximately 9 zeroes for every member, preferrably paid directly to Netstyle? .... I suspect the latter ;) On 5/1/20 12:04 AM, Elad Cohen wrote:
Stuart,
All the bgp routers will be upgraded if I will be elected, you can be sure of it, including EOL routers, there is and there will be solution for anything.
After it all internet users will enjoy from the end of: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking
And the dramatically reducing of: IoT botnet infections and Botnet C&Cs
Respectfully, Elad ------------------------------------------------------------------------ *From:* Stuart Willet (primary) <stu@safehosts.co.uk> *Sent:* Friday, May 1, 2020 12:01 AM *To:* Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <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,
As repeatedly explained to you, it simply is not possible to go around updating EVERY piece of hardware and software used for BGP sessions.
I don’t know why you can’t comprehend this, so I am simply going to stop responding to you.
Respectfully,
Stuart Willet.
*From:*Elad Cohen [mailto:elad@netstyle.io] *Sent:* 30 April 2020 21:59 *To:* Stuart Willet (primary) <stu@safehosts.co.uk>; 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,
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@safehosts.co.uk <mailto:stu@safehosts.co.uk>> *Sent:* Thursday, April 30, 2020 11:54 PM *To:* Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io>>; members-discuss@ripe.net <mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk <mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk <mailto:stu@safehosts.co.uk>> *Sent:* Thursday, April 30, 2020 11:44 PM *To:* Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io>>; members-discuss@ripe.net <mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk <mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk <mailto:stu@safehosts.co.uk>> *Sent:* Thursday, April 30, 2020 11:39 PM *To:* Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io>>; members-discuss@ripe.net <mailto:members-discuss@ripe.net> <members-discuss@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@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@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.f...
Aleksi, Why don't you say directly the candidate that you support ? We all know who he is - it is the useless guy that can only connect network cables. Why he is sending you and not writing himself what he will do for Ripe ? Like I am writing. He seems in a lot of panic. Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces@ripe.net> on behalf of Aleksi <aleksi@magnacapax.fi> Sent: Friday, May 1, 2020 12:37 AM To: members-discuss@ripe.net <members-discuss@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 "All the bgp routers will be upgraded if I will be elected, you can be sure of it, including EOL routers, there is and there will be solution for anything." ROFLMAO! Can we have immortality with infinite money as well on the go? :) Or is this the type of promise where RIPE membership annual fee balloons by approximately 9 zeroes for every member, preferrably paid directly to Netstyle? .... I suspect the latter ;) On 5/1/20 12:04 AM, Elad Cohen wrote: Stuart, All the bgp routers will be upgraded if I will be elected, you can be sure of it, including EOL routers, there is and there will be solution for anything. After it all internet users will enjoy from the end of: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking And the dramatically reducing of: IoT botnet infections and Botnet C&Cs Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu@safehosts.co.uk><mailto:stu@safehosts.co.uk> Sent: Friday, May 1, 2020 12:01 AM To: Elad Cohen <elad@netstyle.io><mailto:elad@netstyle.io>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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, As repeatedly explained to you, it simply is not possible to go around updating EVERY piece of hardware and software used for BGP sessions. I don’t know why you can’t comprehend this, so I am simply going to stop responding to you. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 30 April 2020 21:59 To: Stuart Willet (primary) <stu@safehosts.co.uk><mailto:stu@safehosts.co.uk>; members-discuss@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, 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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@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@ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.f...
The RIPE executive board has no say in such a matter. Elad Cohen <elad@netstyle.io> skrev: (30 april 2020 23:04:31 CEST)
Stuart,
All the bgp routers will be upgraded if I will be elected, you can be sure of it, including EOL routers, there is and there will be solution for anything.
After it all internet users will enjoy from the end of: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking
And the dramatically reducing of: IoT botnet infections and Botnet C&Cs
Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu@safehosts.co.uk> Sent: Friday, May 1, 2020 12:01 AM To: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <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,
As repeatedly explained to you, it simply is not possible to go around updating EVERY piece of hardware and software used for BGP sessions.
I don’t know why you can’t comprehend this, so I am simply going to stop responding to you.
Respectfully,
Stuart Willet.
From: Elad Cohen [mailto:elad@netstyle.io] Sent: 30 April 2020 21:59 To: Stuart Willet (primary) <stu@safehosts.co.uk>; 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,
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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@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
-- Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
-- Andrae Marx
Am 30.04.2020 um 23:04 schrieb Elad Cohen <elad@netstyle.io>:
Stuart,
All the bgp routers will be upgraded if I will be elected, you can be sure of it, including EOL routers, there is and there will be solution for anything.
My i suggest, if you getg voted, that you also change the following things in these planed upgrades, to all bgp related routing devices in the whole internet: - missing ipv6 support on old EOL devices - missing rpki features on old devices - missing support for 4-byte ASN’s on old devices - adding more ressources (cpu, ram) on older routers, which actually are in trouble with these ressources, keeping the whole routing-table, which might not get better, by extending now bgp, with additional information …. (older routers, are limited in these ressources and can not be upgraded) There is a reason, why we have since 20 years IPv6 and it is not fully rolled out and working on the whole world …. there is a reason, why we are not able to change the whole smtp, and have to build work arounds to reduce and filter spam …. We also need to change smtp …. dns …. and maybe everyone should filter udp …. or we just do a fully lockdown of the internet ….. To be really sure, we also can just power off all routers on the world …. no spam any more …. no DDoS attacks any more …. To be serous …. upgrading all and every device on the world, which is speaking bgp, is just not possible …. This is my technical point of view …. My personal point of view is, that this list, should not be used, to discuss this topics here, it was several times told in the last days … and again, the same thing …. There is a way, to present these things …. answering on the call of papers, for the ripe meetings, and doing a presentation there regards, Andi -- Andrae Marx
Hello Elad-19, We are see that you are the good man with interesting ideas. We think you have more interesting ideas. Of Course we will support you on election, but you should promise, that upgrade ours EOL routers without any additional cost, if you will in board. If yours promise will false, we are find you.
From Russia with love.
On Thu, 30 Apr 2020 21:04:31 +0000 Elad Cohen <elad@netstyle.io> wrote:
Stuart,
All the bgp routers will be upgraded if I will be elected, you can be sure of it, including EOL routers, there is and there will be solution for anything.
After it all internet users will enjoy from the end of: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking
And the dramatically reducing of: IoT botnet infections and Botnet C&Cs
Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu@safehosts.co.uk> Sent: Friday, May 1, 2020 12:01 AM To: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <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,
As repeatedly explained to you, it simply is not possible to go around updating EVERY piece of hardware and software used for BGP sessions.
I don’t know why you can’t comprehend this, so I am simply going to stop responding to you.
Respectfully,
Stuart Willet.
From: Elad Cohen [mailto:elad@netstyle.io] Sent: 30 April 2020 21:59 To: Stuart Willet (primary) <stu@safehosts.co.uk>; 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,
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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@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@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
-- Alexandr Gurbo <a.gurbo@severen.ru>
The costs will be much much lower than the impacts of the following:
Spoofed IP traffic
hmmm. isn't the following spoofing too?
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
On 30.04.20 22:59, Elad Cohen wrote:
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@safehosts.co.uk> *Sent:* Thursday, April 30, 2020 11:54 PM *To:* Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <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@safehosts.co.uk>; 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@safehosts.co.uk <mailto:stu@safehosts.co.uk>> *Sent:* Thursday, April 30, 2020 11:44 PM *To:* Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io>>; members-discuss@ripe.net <mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk <mailto:stu@safehosts.co.uk>>; members-discuss@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@safehosts.co.uk <mailto:stu@safehosts.co.uk>> *Sent:* Thursday, April 30, 2020 11:39 PM *To:* Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io>>; members-discuss@ripe.net <mailto:members-discuss@ripe.net> <members-discuss@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@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@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/lists%40velder.li
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@ripe.net> Im Auftrag von Elad Cohen Gesendet: Donnerstag, 30. April 2020 22:59 An: Stuart Willet (primary) <stu@safehosts.co.uk>; members-discuss@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@safehosts.co.uk <mailto:stu@safehosts.co.uk> > Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io> >; members-discuss@ripe.net <mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk <mailto:stu@safehosts.co.uk> >; members-discuss@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@safehosts.co.uk <mailto:stu@safehosts.co.uk> > Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io> >; members-discuss@ripe.net <mailto:members-discuss@ripe.net> <members-discuss@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@safehosts.co.uk <mailto:stu@safehosts.co.uk> >; members-discuss@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@safehosts.co.uk <mailto:stu@safehosts.co.uk> > Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io> >; members-discuss@ripe.net <members-discuss@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@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
Hi! What about the internet traffic in doubling every packet and the electrical power to do the cryptographic operations? Or do you want to make every router in the world stateful? As much as I would love to see you elected and make a complete fool of yourself, I can not risk the reputation of RIPE... At the moment I do not fancy any candidate, nor do I support one. Matthias Am 30.04.20 um 22:50 schrieb Elad Cohen:
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@safehosts.co.uk> *Sent:* Thursday, April 30, 2020 11:44 PM *To:* Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <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@safehosts.co.uk>; 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@safehosts.co.uk <mailto:stu@safehosts.co.uk>> *Sent:* Thursday, April 30, 2020 11:39 PM *To:* Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io>>; members-discuss@ripe.net <mailto:members-discuss@ripe.net> <members-discuss@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@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@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net
-- Unser Familien-Blog: https://brumm.family
This was not attack against you Elad, but argument against your "idea". Just because someone does not like all your ideas does not mean they are against you personally. You are not gaining any favors by spamming other RIPE members like this, you've been asked to stop numerous times now and it's been exposed this is probably an election campaign. So therefore, i would bet most on this list are against you personally at this point as well. It does not help that you have connections to some shady dealings like the south african IP hijacking. Neither does the irony of your signature ... (everyone else, get the popcorn ready!) On 4/30/20 11:41 PM, Elad Cohen wrote:
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@safehosts.co.uk> *Sent:* Thursday, April 30, 2020 11:39 PM *To:* Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <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@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@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.f...
Please no more "technical solutions" on members-discuss! - Cynthia On Thu, Apr 30, 2020 at 10:31 PM Elad Cohen <elad@netstyle.io> wrote:
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@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re
Cynthia, This is a presentation that I will show in the near General Meeting. Respectfully, Elad ________________________________ From: Cynthia Revström <me@cynthia.re> Sent: Thursday, April 30, 2020 11:57 PM To: Elad Cohen <elad@netstyle.io> Cc: members-discuss@ripe.net <members-discuss@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 Please no more "technical solutions" on members-discuss! - Cynthia On Thu, Apr 30, 2020 at 10:31 PM Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>> wrote: 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@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
Dear all, May I remind you what the purpose of this list is?
This is a list for RIPE NCC members to discuss **membership-related issues.**
I find myself wondering if my understanding of the definition of "membership-related issues" is somehow flawed. It would appear that this list was turned into a media for distributing political speeches in order to get votes in the upcoming elections. Quoting RIPE Mailing List Code of Conduct here:
RIPE community members **should not spam mailing lists**, post others' personal information, register multiple accounts to avoid moderation or mislead participants, impersonate others, or make threats. **Overt marketing or promotional activities are discouraged.**
I would like to point out that the discussions of the past few days are - at least, according to my interpretation - in direct violation of several of the aforementioned rules.
Chairs are responsible for facilitating and moderating the RIPE community's discussions. At times they may direct an individual to cease a certain type of behaviour. Chairs have the authority to moderate or ban disruptive community members if they decide this is necessary.
As such, I would like to request the relevant Chair (I wasn't able to find out who that is) to step in and moderate the list properly please! Enough is enough. Thank you very much. Best Regards, Filip Hruška On 4/30/20 10:57 PM, Cynthia Revström wrote:
Please no more "technical solutions" on members-discuss!
- Cynthia
On Thu, Apr 30, 2020 at 10:31 PM Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io>> wrote:
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@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@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/fhr%40fhrnet.eu
-- Filip Hruska Linux System Administrator
1. BGP routers are no IPS devices. 2. BGP routers have better things to do than doing crypto-stuff on a massive scale 3. at this point I suspected a joke (ok, the rest of the mail is just hilarious):
- 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.
Am 30.04.20 um 22:30 schrieb Elad Cohen:
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@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net
-- Unser Familien-Blog: https://brumm.family
Yes, BGP routers need to handle all the DDoS attacks, it will be better for them. Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces@ripe.net> on behalf of Matthias Brumm <matthias@brumm.net> Sent: Friday, May 1, 2020 12:04 AM To: members-discuss@ripe.net <members-discuss@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 1. BGP routers are no IPS devices. 2. BGP routers have better things to do than doing crypto-stuff on a massive scale 3. at this point I suspected a joke (ok, the rest of the mail is just hilarious): - 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. Am 30.04.20 um 22:30 schrieb Elad Cohen: 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@ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family
Dear members of this list, how about we take a different approach and "pretend" to agree with everything Mr Cohen has to say.. Lets tell him that we want more technical solutions like he suggests, maybe this would get him to actually take time to write about new proposals (which would mean he would not have time to troll this list) Elan you want to solve the IPv4 problem, now the DDoS problem. Can you maybe come with a solution for Spam too? Don't you think that there should be a central registry for managing spam blacklists and whitelists and so on. Maybe you can be the pioneer of this, you can use your skill to create something? Yeah guys just encourage him to do work brijg bring new ideas (or whatever gets him to not post here)... Just instead of finding out the flaws in his ideas or telling him ripe board has no right or power to do things like that or whatever, just tell him otherwise...
The main thing is that I'm not writing anything, I'm only responding, you are the trolls that are spamming this list. Now another one of them will jump again. Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces@ripe.net> on behalf of Bora Ismen <bora.ismen@nimbevo.com> Sent: Friday, May 1, 2020 1:40 AM To: members-discuss@ripe.net <members-discuss@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 Dear members of this list, how about we take a different approach and "pretend" to agree with everything Mr Cohen has to say.. Lets tell him that we want more technical solutions like he suggests, maybe this would get him to actually take time to write about new proposals (which would mean he would not have time to troll this list) Elan you want to solve the IPv4 problem, now the DDoS problem. Can you maybe come with a solution for Spam too? Don't you think that there should be a central registry for managing spam blacklists and whitelists and so on. Maybe you can be the pioneer of this, you can use your skill to create something? Yeah guys just encourage him to do work brijg bring new ideas (or whatever gets him to not post here)... Just instead of finding out the flaws in his ideas or telling him ripe board has no right or power to do things like that or whatever, just tell him otherwise...
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
I think this guy is the new local donald trump Sent from my iPhone
On 1 May 2020, at 02:10, Gert Doering <gert@space.net> wrote:
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 _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/suport%40bunea.eu
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. Your posts are offtopic and aren't within purpose of this maillist (Reference: Mailing List Purpose and Request for Consideration , from RIPE, Piotr Strzyżewski, this Monday). It is frankly arrogant and not very smart ignoring that, and you keep
On 2020-04-30 23:30, Elad Cohen wrote: trying to use this mailing list as an podium for election campaign. These "solutions" technically illiterate, hard-to-implement(not feasible in most of cases) ideas that look convincing only to people who do not have knowledge in the relevant fields, but to the anybody with experience look quite inadequate (most polite word for it). Meanwhile, i am surprised that someone liked this nonsense, i hope it was sarcasm. I really hope common sense exist and person who offers technically inadequate solutions that undermine existing standards, throw accusations left and right, build conspiracy theories, ignore purpose of maillists - will not be elected. P.S. For members who will vote, worth reading, especially second article: https://mybroadband.co.za/news/internet/330379-how-internet-resources-worth-... https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-addr...
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. Your posts are offtopic and aren't within purpose of this maillist (Reference: Mailing List Purpose and Request for Consideration , from RIPE, Piotr Strzyżewski, this Monday). It is frankly arrogant and not very smart ignoring that, and you keep
Denys, My response to your post: The cyber influence operation against me continue, IPv6 deployers are afraid from me being elected and from me doing everything possible to implement IPv4+ which will bring more than 800,000,000 IPv4 addresses to Ripe that Ripe will be able to give to Ripe LIR members. Regarding the two fake media reports, the source in them is a member of "The Spamhaus Project", an illegal anonymous organization that according to its own presentation in the following link (https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Viol...) is receiving on a regular basis a massive amount of illegal-obtained privacy data of internet users from many internet companies and internet organizations and then share it in illegal way (without any warrant) - with Law Enforcement Agencies. That "source" of the the two fake media reports is also an employee of the company GeoEdge which is a direct competitor of the company that used the netblock in the two fake media reports and the whole intention was to hurt their competitors, besides it the "source" is also the owner of the criminal anonymous twitter account: https://twitter.com/underthebreach - according to his words in his own criminal anonymous account he is writing on himself that he is a master of cyber influence operations (meaning to create fake stories without a single proof). People which are related to other candidates are spreading lies only because they are afraid from the implementation of IPv4+. There isn't any single proof against me in the two fake media reports and there will never will be, because it is all an illegal cyber influence operation by the criminal https://twitter.com/underthebreach which is an employee of a direct competitor of the company which used the netblock. Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces@ripe.net> on behalf of Denys Fedoryshchenko <nuclearcat@nuclearcat.com> Sent: Friday, May 1, 2020 12:24 AM To: members-discuss@ripe.net <members-discuss@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 On 2020-04-30 23:30, Elad Cohen wrote: trying to use this mailing list as an podium for election campaign. These "solutions" technically illiterate, hard-to-implement(not feasible in most of cases) ideas that look convincing only to people who do not have knowledge in the relevant fields, but to the anybody with experience look quite inadequate (most polite word for it). Meanwhile, i am surprised that someone liked this nonsense, i hope it was sarcasm. I really hope common sense exist and person who offers technically inadequate solutions that undermine existing standards, throw accusations left and right, build conspiracy theories, ignore purpose of maillists - will not be elected. P.S. For members who will vote, worth reading, especially second article: https://mybroadband.co.za/news/internet/330379-how-internet-resources-worth-... https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-addr... _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/elad%40netstyle.io
Peace, Trying to be as technical as I can here, On Thu, Apr 30, 2020 at 11:31 PM Elad Cohen <elad@netstyle.io> wrote:
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
So the secret part would be the same for all the packets. This technique is easily circumventable with tcpdump. Moreover, you're encrypting values from a less than 4-byte domain. I can pick the correct encrypted value with brute force. Proper cryptoanalysis would find more flaws in this. I just cherry picked instant weaknesses.
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
This is not how border routers work. Those do not keep a packet in memory until some check-up would finish. They are *stateless* when it comes to forwarding packets, otherwise they could be DDoS'd much easily than today. IOW, they do not *know anything* about other packets while processing your "tracking packet". What if a tracking packet is lost in transit? What if it arrives an hour later? How long does it take for a router to drop a packet without a confirmation? "X number of seconds" is not a response. "Seconds" are a wrong unit of measurement. Nanoseconds, maybe. Seconds — no go. That also assumes a hardware update to all the line cards.
- 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.
Also if we can block all the weapon-producing plants there would be no war from that point on. Why don't you apply your genius to those certainly more important issues of the humanity?
any kind of automatic updating (in the operating system configurations) will be disabled
This is not how vulnerabilities work. They are frequently *introduced* by an update. I'm waiting for your financial analysis of the concept "let's keep a VM for every published CVE" (assuming that every actively exploited vulnerability even gets a CVE, which is also not how it works).
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
This is not gonna work for P2P botnets. *** I must have missed other flaws, the e-mail is insanely tough to read (possibly intentionally). Anyhow, RIPE is *not* the place for such proposals. IETF secdispatch is (Gosh may Kathleen and Roman forgive me): secdispatch@ietf.org. -- Töma
Ah yes!! On Thu, Apr 30, 2020 at 11:31 PM Elad Cohen <elad@netstyle.io> wrote:
- 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.
Everywhere except for China and, possibly, North Korea, border routers are *not* DPI devices. Hence they don't have an *ability* to *look* through the IP packet data, let alone apply any checksums or fingerprints. Otherwise, gosh, TCP with its checksums wouldn't have been necessary. A DPI device costs I think 500 times more than a typical border routing device in use in Europe. (this is a rough estimation based on the packet length, it might be slight less or a couple orders of magnitude more than that) And yes. This solution requires a complete *hardware* update to all the border routers. I think that's a concept for a PhD topic in economy (quite possibly also a Nobel prize) rather than for a members-discuss thread. P.S. I want to reiterate that those topics are relevant to secdispatch@ietf.org. Only after they are submitted as an I-D and dispatched to a working group, AND the working group accepts the I-D as a working group draft, they are on-topic in here. Otherwise, they are off-topic. Thank you in advance for understanding. -- Töma
Toma, You are rising interesting issues. It will be interesting to hear from hardware engineers that are working in the routing equipment manufaturers. Even that not any router is DPI as you wrote, BGP routers have ACL's functionality, for implementing the ACL checks - the firmware is inspecting the ip packet in some way, an inspection is being done to the ip packet in any BGP router that support ACL's. Respectfully, Elad ________________________________ From: Töma Gavrichenkov <ximaera@gmail.com> Sent: Friday, May 1, 2020 12:58 AM To: Elad Cohen <elad@netstyle.io> Cc: members-discuss@ripe.net <members-discuss@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 Ah yes!! On Thu, Apr 30, 2020 at 11:31 PM Elad Cohen <elad@netstyle.io> wrote:
- 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.
Everywhere except for China and, possibly, North Korea, border routers are *not* DPI devices. Hence they don't have an *ability* to *look* through the IP packet data, let alone apply any checksums or fingerprints. Otherwise, gosh, TCP with its checksums wouldn't have been necessary. A DPI device costs I think 500 times more than a typical border routing device in use in Europe. (this is a rough estimation based on the packet length, it might be slight less or a couple orders of magnitude more than that) And yes. This solution requires a complete *hardware* update to all the border routers. I think that's a concept for a PhD topic in economy (quite possibly also a Nobel prize) rather than for a members-discuss thread. P.S. I want to reiterate that those topics are relevant to secdispatch@ietf.org. Only after they are submitted as an I-D and dispatched to a working group, AND the working group accepts the I-D as a working group draft, they are on-topic in here. Otherwise, they are off-topic. Thank you in advance for understanding. -- Töma
Peace, On Fri, May 1, 2020 at 1:17 AM Elad Cohen <elad@netstyle.io> wrote:
It will be interesting to hear from hardware engineers that are working in the routing equipment manufaturers.
I've done that before, myself. I have a long career path in telecom. Here's what you do: reach out to them directly. They are not ISPs, therefore they are *not* subscribed to members-discuss at ripe dot net. Prepare to hear curses or rude jokes. I warned you.
Even that not any router is DPI as you wrote, BGP routers have ACL's functionality, for implementing the ACL checks - the firmware is inspecting the ip packet in some way
This only has the word "functionality" in common with what you need to implement what you propose. But the functionality is completely different across the areas. You don't seem to have done your homework.
Respectfully,
Please, don't bother. -- Töma
Toma, ------ This is not how border routers work. Those do not keep a packet in memory until some check-up would finish. They are *stateless* when it comes to forwarding packets, otherwise they could be DDoS'd much easily than today. IOW, they do not *know anything* about other packets while processing your "tracking packet". What if a tracking packet is lost in transit? What if it arrives an hour later? How long does it take for a router to drop a packet without a confirmation? ------ The firmware - the upgraded software - is set how the router works - even if it intentionally intended to be stateless. If a tracking packet is lost in transit then this is exactly such as the original ip packet is lost in transit - the source and destination will communicate between themselves when the ip packet wasn't received. There will be a timeout for the tracking ip packet so an hour later will be too late. Round table of the RIRs and routing equipment manufacturers will set the timeout value. ------ This is not how vulnerabilities work. They are frequently *introduced* by an update. I'm waiting for your financial analysis of the concept "let's keep a VM for every published CVE" (assuming that every actively exploited vulnerability even gets a CVE, which is also not how it works). ------ Vulnerabilities can be at the templates as well, and as you wrote also in the updates, updates can be performed in a monitored way so the system will know exactly which VM's have which updates. No - I didn't write lets keep a VM for every published CVE, Each VM can have vulnerabilities of many CVE's. ------ This is not gonna work for P2P botnets. ------ Yes, but they are not the majority of botnets, one step at a time. ----- (possibly intentionally). ----- Yes, intentionally. Respectfully, Elad ________________________________ From: Töma Gavrichenkov <ximaera@gmail.com> Sent: Friday, May 1, 2020 12:33 AM To: Elad Cohen <elad@netstyle.io> Cc: members-discuss@ripe.net <members-discuss@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 Peace, Trying to be as technical as I can here, On Thu, Apr 30, 2020 at 11:31 PM Elad Cohen <elad@netstyle.io> wrote:
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
So the secret part would be the same for all the packets. This technique is easily circumventable with tcpdump. Moreover, you're encrypting values from a less than 4-byte domain. I can pick the correct encrypted value with brute force. Proper cryptoanalysis would find more flaws in this. I just cherry picked instant weaknesses.
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
This is not how border routers work. Those do not keep a packet in memory until some check-up would finish. They are *stateless* when it comes to forwarding packets, otherwise they could be DDoS'd much easily than today. IOW, they do not *know anything* about other packets while processing your "tracking packet". What if a tracking packet is lost in transit? What if it arrives an hour later? How long does it take for a router to drop a packet without a confirmation? "X number of seconds" is not a response. "Seconds" are a wrong unit of measurement. Nanoseconds, maybe. Seconds — no go. That also assumes a hardware update to all the line cards.
- 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.
Also if we can block all the weapon-producing plants there would be no war from that point on. Why don't you apply your genius to those certainly more important issues of the humanity?
any kind of automatic updating (in the operating system configurations) will be disabled
This is not how vulnerabilities work. They are frequently *introduced* by an update. I'm waiting for your financial analysis of the concept "let's keep a VM for every published CVE" (assuming that every actively exploited vulnerability even gets a CVE, which is also not how it works).
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
This is not gonna work for P2P botnets. *** I must have missed other flaws, the e-mail is insanely tough to read (possibly intentionally). Anyhow, RIPE is *not* the place for such proposals. IETF secdispatch is (Gosh may Kathleen and Roman forgive me): secdispatch@ietf.org. -- Töma
Peace,
I must have missed other flaws, the e-mail is insanely tough to read (possibly intentionally).
Yes, intentionally.
So you just confirmed that you're sending intentionally unreadable e-mails to a RIPE mailing list of some tens of thousands subscribers. If this doesn't cause you being moderated then I don't know what would. -- Töma
No, it is readable to everyone, it was intentionally unreadable only to you. Respectfully, Elad ________________________________ From: Töma Gavrichenkov <ximaera@gmail.com> Sent: Friday, May 1, 2020 1:07 AM To: Elad Cohen <elad@netstyle.io> Cc: members-discuss@ripe.net <members-discuss@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 Peace,
I must have missed other flaws, the e-mail is insanely tough to read (possibly intentionally).
Yes, intentionally.
So you just confirmed that you're sending intentionally unreadable e-mails to a RIPE mailing list of some tens of thousands subscribers. If this doesn't cause you being moderated then I don't know what would. -- Töma
This is unacceptable the way you conduct yourself on these email lists. I have submit a formal complaint to RIPE it is a gross violation of community standards. Sent from my iPhone
On Apr 30, 2020, at 16:31, Elad Cohen <elad@netstyle.io> wrote:
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@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/joreilly%40nellicus.n...
Brilliant, just did the same. -- shrd. - Saint Honoré Recherche & Développement Pour toute demande technique : support@shrd.fr Incidents / Informations : http://blog.shrd.fr/ Courrier : 91 rue du Faubourg Saint Honoré - 75008 Paris Nos serveurs sont (bien) élevés en France exclusivement
On 30 Apr 2020, at 23:33, Justin O’Reilly <joreilly@nellicus.net> wrote:
This is unacceptable the way you conduct yourself on these email lists. I have submit a formal complaint to RIPE it is a gross violation of community standards.
As this idea is talking about BGP implementations I think this would belong in the IDR WG in IETF? On Thu, Apr 30, 2020 at 10:32 PM Elad Cohen <elad@netstyle.io> wrote:
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@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-members-discussi...
Hello together, Elad, can you proove that you are indeed the nominated candidate for the RIPE NCC Executive Board? Why are you writing with an address from the "Indian Ocean Area" which does not belong to the Region covered by RIPE ? Many things made me wondering, if the flood of mails in this list was maybe a Joe-Job. If it was indeed authentic, it seems to me like an advertisement to be *not* elected. Maybe hazard, maybe it is intention that these heavy discussions are started when the RIPE NCC team goes in the weekend and/or hollydays and cannot moderate the list immedeately. IMHO the technical proposals are 1) not fitting in the purpose of THIS mailing list and 2) already more deeply discussed items in former dedaces. This will be my only reply to this discussion and I would be glad if such off-topic discussions won't flood my mailbox anymore. Regards, Andreas
Omfg here we go again with the spam and “technical solutions” just leave it already! -- Met Vriendelijke Groet, Wesley Berendsen -verstuurd vanaf mijn iPhone-
Op 30 apr. 2020 om 22:32 heeft Elad Cohen <elad@netstyle.io> het volgende geschreven:
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@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/wesley%40gxw.nl
I'm only trying to help. Respectfully, Elad ________________________________ From: Wesley Berendsen | GXW.nl <wesley@gxw.nl> Sent: Friday, May 1, 2020 1:16 AM To: Elad Cohen <elad@netstyle.io> Cc: members-discuss@ripe.net <members-discuss@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 Omfg here we go again with the spam and “technical solutions” just leave it already! -- Met Vriendelijke Groet, Wesley Berendsen -verstuurd vanaf mijn iPhone- Op 30 apr. 2020 om 22:32 heeft Elad Cohen <elad@netstyle.io> het volgende geschreven: 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@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/wesley%40gxw.nl
Hi Elad, in Germany we have an phrase that reads as follows: "The opposite of well is well-meaning." Regards, Bene On 01.05.20 00:18, Elad Cohen wrote:
I'm only trying to help.
Respectfully, Elad ------------------------------------------------------------------------ *From:* Wesley Berendsen | GXW.nl <wesley@gxw.nl> *Sent:* Friday, May 1, 2020 1:16 AM *To:* Elad Cohen <elad@netstyle.io> *Cc:* members-discuss@ripe.net <members-discuss@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 Omfg here we go again with the spam and “technical solutions” just leave it already!
--
Met Vriendelijke Groet,
Wesley Berendsen -verstuurd vanaf mijn iPhone-
Op 30 apr. 2020 om 22:32 heeft Elad Cohen <elad@netstyle.io> het volgende geschreven:
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@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/wesley%40gxw.nl
_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe.discuss%40itfrie...
participants (28)
-
Aleksi -
Alexandr Gurbo -
Andrae Marx -
Andreas Schmieja -
Benedikt Neuffer -
Bora Ismen -
Bunea Petru -
Cynthia Revström -
Denys Fedoryshchenko -
Elad Cohen -
Filip Hruska -
Gert Doering -
info＠cowmedia.de -
Jaroslav Skřivan -
Justin O’Reilly -
Leopold Schabel -
Matthias Brumm -
Melchior Aelmans -
Michel Luczak (SHRD) -
Munir Badr -
Oscar Wieman -
Patrick Velder -
Peter Linder -
Ryan Hamel -
Siyuan Miao -
Stuart Willet (primary) -
Töma Gavrichenkov -
Wesley Berendsen | GXW.nl