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