[members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs

> 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 at safehosts.co.uk>
> *Sent:* Thursday, April 30, 2020 11:54 PM
> *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,
>
> 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>; 
> 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
>
>
> _______________________________________________
> members-discuss mailing list
> members-discuss at ripe.net
> https://mailman.ripe.net/
> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/lists%40velder.li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20200430/fd3fb2e3/attachment.html>