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

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://mailman.ripe.net/
>>> Unsubscribe:
>>> https://lists.ripe.net/mailman/options/members-discuss/ripe-members-discussion%40coloclue.net
>>>
>> _______________________________________________
>> members-discuss mailing list
>> members-discuss at ripe.net
>> https://mailman.ripe.net/
>> Unsubscribe:
>> https://lists.ripe.net/mailman/options/members-discuss/ripe%40tmo.sh
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20200501/5f0a3b87/attachment.html>