[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] [SPAM] Re: 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 ]
Patrick Velder
lists at velder.li
Thu Apr 30 23:23:50 CEST 2020
> 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://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/lists%40velder.li -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/members-discuss/attachments/20200430/fd3fb2e3/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] [SPAM] Re: 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 ]