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

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://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
>>>
>> _______________________________________________
> members-discuss mailing list
> members-discuss at ripe.net
> https://mailman.ripe.net/
> Unsubscribe:
> https://lists.ripe.net/mailman/options/members-discuss/ciprian.pantea%40innovocompany.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20200501/7e607cf4/attachment.html>