[members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
- Previous message (by thread): [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
- Next message (by thread): [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Peter Linder
peter at fiberdirekt.se
Thu Apr 30 23:38:13 CEST 2020
The RIPE executive board has no say in such a matter. Elad Cohen <elad at 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 at safehosts.co.uk> >Sent: Friday, May 1, 2020 12:01 AM >To: Elad Cohen <elad at netstyle.io>; members-discuss at ripe.net ><members-discuss at 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 at netstyle.io] >Sent: 30 April 2020 21:59 >To: Stuart Willet (primary) <stu at safehosts.co.uk>; >members-discuss at 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 at safehosts.co.uk<mailto:stu at safehosts.co.uk>> >Sent: Thursday, April 30, 2020 11:54 PM >To: Elad Cohen <elad at netstyle.io<mailto:elad at netstyle.io>>; >members-discuss at ripe.net<mailto:members-discuss at ripe.net> ><members-discuss at ripe.net<mailto:members-discuss at 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 at netstyle.io] >Sent: 30 April 2020 21:50 >To: Stuart Willet (primary) ><stu at safehosts.co.uk<mailto:stu at safehosts.co.uk>>; >members-discuss at ripe.net<mailto:members-discuss at 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 at safehosts.co.uk<mailto:stu at safehosts.co.uk>> >Sent: Thursday, April 30, 2020 11:44 PM >To: Elad Cohen <elad at netstyle.io<mailto:elad at netstyle.io>>; >members-discuss at ripe.net<mailto:members-discuss at ripe.net> ><members-discuss at ripe.net<mailto:members-discuss at 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 at netstyle.io] >Sent: 30 April 2020 21:42 >To: Stuart Willet (primary) ><stu at safehosts.co.uk<mailto:stu at safehosts.co.uk>>; >members-discuss at ripe.net<mailto:members-discuss at 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 at safehosts.co.uk<mailto:stu at safehosts.co.uk>> >Sent: Thursday, April 30, 2020 11:39 PM >To: Elad Cohen <elad at netstyle.io<mailto:elad at netstyle.io>>; >members-discuss at ripe.net<mailto:members-discuss at ripe.net> ><members-discuss at ripe.net<mailto:members-discuss at 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 at ripe.net] On >Behalf Of Elad Cohen >Sent: 30 April 2020 21:31 >To: members-discuss at ripe.net<mailto:members-discuss at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/members-discuss/attachments/20200430/bf49deb3/attachment.html>
- Previous message (by thread): [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
- Next message (by thread): [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]