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

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://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20200430/bf49deb3/attachment.html>