[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 at 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 at ripe.net
> https://lists.ripe.net/mailman/listinfo/members-discuss
> Unsubscribe:
> https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/members-discuss/attachments/20200430/8ddea245/attachment.html>