[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 ]
Melchior Aelmans
melchior at aelmans.eu
Fri May 1 10:06:30 CEST 2020
LOL On Fri, May 1, 2020 at 1:08 AM Thilo <inbox at tmo.sh> wrote: > IAB is also having open chair positions if this is something out of > interest. > > Am Fr., 1. Mai 2020 um 00:53 Uhr schrieb Melchior Aelmans < > melchior at aelmans.eu>: > >> As this idea is talking about BGP implementations I think this would >> belong in the IDR WG in IETF? >> >> On Thu, Apr 30, 2020 at 10:32 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/ripe-members-discussion%40coloclue.net >>> >> _______________________________________________ >> 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/ripe%40tmo.sh >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/members-discuss/attachments/20200501/5f0a3b87/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 ]