<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Toma, <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span>------<br>
</span>
<div><span style="font-size: 11pt;">This is not how border routers work. Those do not keep a packet in</span><br>
</div>
<div><span style="font-size: 11pt;">memory until some check-up would finish. They are *stateless* when it</span><br>
</div>
<div><span style="font-size: 11pt;">comes to forwarding packets, otherwise they could be DDoS'd much</span><br>
</div>
<div><span style="font-size: 11pt;">easily than today. IOW, they do not *know anything* about other</span><br>
</div>
<div><span style="font-size: 11pt;">packets while processing your "tracking packet".</span><br>
</div>
<div><br>
</div>
<div><span style="font-size: 11pt;">What if a tracking packet is lost in transit? What if it arrives an</span><br>
</div>
<div><span style="font-size: 11pt;">hour later? How long does it take for a router to drop a packet</span><br>
</div>
<div><span style="font-size: 11pt;">without a confirmation?</span><br>
</div>
<div>------<br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>------<br>
</div>
<div><span style="font-size: 11pt;">This is not how vulnerabilities work. They are frequently</span><br>
</div>
<div><span style="font-size: 11pt;">*introduced* by an update.</span><br>
</div>
<div><br>
</div>
<div><span style="font-size: 11pt;">I'm waiting for your financial analysis of the concept "let's keep a</span><br>
</div>
<div><span style="font-size: 11pt;">VM for every published CVE" (assuming that every actively exploited</span><br>
</div>
<div><span style="font-size: 11pt;">vulnerability even gets a CVE, which is also not how it works).</span><br>
</div>
<div>------<br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>------<br>
</div>
<div><span style="font-size: 11pt;">This is not gonna work for P2P botnets.</span><br>
</div>
<div>------<br>
</div>
<div>Yes, but they are not the majority of botnets, one step at a time.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>-----<br>
</div>
<div><span style="font-size: 11pt;">(possibly intentionally).</span><br>
</div>
<div>-----<br>
</div>
<div>Yes, intentionally.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Respectfully,<br>
</div>
<span>Elad</span><br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Töma Gavrichenkov <ximaera@gmail.com><br>
<b>Sent:</b> Friday, May 1, 2020 12:33 AM<br>
<b>To:</b> Elad Cohen <elad@netstyle.io><br>
<b>Cc:</b> members-discuss@ripe.net <members-discuss@ripe.net><br>
<b>Subject:</b> Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Peace,<br>
<br>
Trying to be as technical as I can here,<br>
<br>
On Thu, Apr 30, 2020 at 11:31 PM Elad Cohen <elad@netstyle.io> wrote:<br>
> In the new tracking ip packet there will be a new<br>
> transport layer protocol (tracking protocol) with<br>
> the following fields:<br>
> AS number of source BGP router in clear text<br>
> AS number of source BGP router encrypted with the private key of the source BGP router<br>
<br>
So the secret part would be the same for all the packets. This<br>
technique is easily circumventable with tcpdump.<br>
<br>
Moreover, you're encrypting values from a less than 4-byte domain. I<br>
can pick the correct encrypted value with brute force.<br>
<br>
Proper cryptoanalysis would find more flaws in this. I just cherry<br>
picked instant weaknesses.<br>
<br>
<br>
> If 'on' then the destination BGP router will decrypt<br>
> the 'encrypted AS number' with the public key of<br>
> the specific AS number<br>
> and after decryption the AS number need to be<br>
> the result:<br>
> if not then to drop the tracking ip packet and the<br>
> original ip packet related to it<br>
> if yes then to drop the tracking ip packet and to<br>
> forward the related original ip packet to<br>
> destination<br>
<br>
This is not how border routers work. Those do not keep a packet in<br>
memory until some check-up would finish. They are *stateless* when it<br>
comes to forwarding packets, otherwise they could be DDoS'd much<br>
easily than today. IOW, they do not *know anything* about other<br>
packets while processing your "tracking packet".<br>
<br>
What if a tracking packet is lost in transit? What if it arrives an<br>
hour later? How long does it take for a router to drop a packet<br>
without a confirmation?<br>
<br>
"X number of seconds" is not a response. "Seconds" are a wrong unit<br>
of measurement. Nanoseconds, maybe. Seconds — no go.<br>
<br>
That also assumes a hardware update to all the line cards.<br>
<br>
<br>
> - IoT botnets are based on default credentials, if we<br>
> can block default credentials of IoT devices then<br>
> these kind of botnets (such as Mirai-variants and<br>
> similar) will stop to have an impact in the internet.<br>
<br>
Also if we can block all the weapon-producing plants there would be no<br>
war from that point on.<br>
<br>
Why don't you apply your genius to those certainly more important<br>
issues of the humanity?<br>
<br>
<br>
> any kind of automatic updating (in the operating<br>
> system configurations) will be disabled<br>
<br>
This is not how vulnerabilities work. They are frequently<br>
*introduced* by an update.<br>
<br>
I'm waiting for your financial analysis of the concept "let's keep a<br>
VM for every published CVE" (assuming that every actively exploited<br>
vulnerability even gets a CVE, which is also not how it works).<br>
<br>
<br>
> the virtual routers will monitor if any outgoing<br>
> connection is made and if yes then it is to a<br>
> botnet C&C, the virtual router will update<br>
> the ICANN backend infrastructure regarding<br>
> it<br>
<br>
This is not gonna work for P2P botnets.<br>
<br>
***<br>
<br>
I must have missed other flaws, the e-mail is insanely tough to read<br>
(possibly intentionally).<br>
<br>
Anyhow, RIPE is *not* the place for such proposals. IETF secdispatch<br>
is (Gosh may Kathleen and Roman forgive me): secdispatch@ietf.org.<br>
<br>
--<br>
Töma<br>
</div>
</span></font></div>
</body>
</html>