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

Toma,

------
This is not how border routers work.  Those do not keep a packet in
memory until some check-up would finish.  They are *stateless* when it
comes to forwarding packets, otherwise they could be DDoS'd much
easily than today.  IOW, they do not *know anything* about other
packets while processing your "tracking packet".

What if a tracking packet is lost in transit?  What if it arrives an
hour later?  How long does it take for a router to drop a packet
without a confirmation?
------
The firmware - the upgraded software - is set how the router works - even if it intentionally intended to be stateless. If a tracking packet is lost in transit then this is exactly such as the original ip packet is lost in transit - the source and destination will communicate between themselves when the ip packet wasn't received. There will be a timeout for the tracking ip packet so an hour later will be too late. Round table of the RIRs and routing equipment manufacturers will set the timeout value.


------
This is not how vulnerabilities work.  They are frequently
*introduced* by an update.

I'm waiting for your financial analysis of the concept "let's keep a
VM for every published CVE" (assuming that every actively exploited
vulnerability even gets a CVE, which is also not how it works).
------
Vulnerabilities can be at the templates as well, and as you wrote also in the updates, updates can be performed in a monitored way so the system will know exactly which VM's have which updates. No - I didn't write lets keep a VM for every published CVE, Each VM can have vulnerabilities of many CVE's.


------
This is not gonna work for P2P botnets.
------
Yes, but they are not the majority of botnets, one step at a time.


-----
(possibly intentionally).
-----
Yes, intentionally.


Respectfully,
Elad
________________________________
From: Töma Gavrichenkov <ximaera at gmail.com>
Sent: Friday, May 1, 2020 12:33 AM
To: Elad Cohen <elad at netstyle.io>
Cc: members-discuss at ripe.net <members-discuss at ripe.net>
Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs

Peace,

Trying to be as technical as I can here,

On Thu, Apr 30, 2020 at 11:31 PM Elad Cohen <elad at netstyle.io> wrote:
> 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

So the secret part would be the same for all the packets.  This
technique is easily circumventable with tcpdump.

Moreover, you're encrypting values from a less than 4-byte domain.  I
can pick the correct encrypted value with brute force.

Proper cryptoanalysis would find more flaws in this.  I just cherry
picked instant weaknesses.


> 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

This is not how border routers work.  Those do not keep a packet in
memory until some check-up would finish.  They are *stateless* when it
comes to forwarding packets, otherwise they could be DDoS'd much
easily than today.  IOW, they do not *know anything* about other
packets while processing your "tracking packet".

What if a tracking packet is lost in transit?  What if it arrives an
hour later?  How long does it take for a router to drop a packet
without a confirmation?

"X number of seconds" is not a response.  "Seconds" are a wrong unit
of measurement.  Nanoseconds, maybe.  Seconds — no go.

That also assumes a hardware update to all the line cards.


> - 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.

Also if we can block all the weapon-producing plants there would be no
war from that point on.

Why don't you apply your genius to those certainly more important
issues of the humanity?


> any kind of automatic updating (in the operating
> system configurations) will be disabled

This is not how vulnerabilities work.  They are frequently
*introduced* by an update.

I'm waiting for your financial analysis of the concept "let's keep a
VM for every published CVE" (assuming that every actively exploited
vulnerability even gets a CVE, which is also not how it works).


> 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

This is not gonna work for P2P botnets.

***

I must have missed other flaws, the e-mail is insanely tough to read
(possibly intentionally).

Anyhow, RIPE is *not* the place for such proposals. IETF secdispatch
is (Gosh may Kathleen and Roman forgive me): secdispatch at ietf.org.

--
Töma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20200430/7ca10e07/attachment.html>