[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 ]
Ciprian Pantea
ciprian.pantea at innovocompany.com
Fri May 1 10:09:28 CEST 2020
How do you unsubscribe from this mailing list? I tried unsubscribing three times and everytime after succeeding I got the welcome message and got back on the list. I would hate to mark this as spam but I will soon enough... Best regards, -- Ciprian Pantea | +4 0743 7016 75 | ciprian.pantea at innovocompany.com Innovo Consulting SRL, RO 24583785, J12/4066/2008 http://innovocompany.com On Fri, May 1, 2020 at 11:08 AM Melchior Aelmans <melchior at aelmans.eu> wrote: > 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 >>> >> _______________________________________________ > 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/ciprian.pantea%40innovocompany.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/members-discuss/attachments/20200501/7e607cf4/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 ]