<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
This was not attack against you Elad, but argument against your
"idea". Just because someone does not like all your ideas does not
mean they are against you personally.<br>
<br>
You are not gaining any favors by spamming other RIPE members like
this, you've been asked to stop numerous times now and it's been
exposed this is probably an election campaign. So therefore, i would
bet most on this list are against you personally at this point as
well. It does not help that you have connections to some shady
dealings like the south african IP hijacking. Neither does the irony
of your signature ...<br>
<br>
(everyone else, get the popcorn ready!)<br>
<p><br>
</p>
<div class="moz-cite-prefix">On 4/30/20 11:41 PM, Elad Cohen wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DB7PR10MB215459FFD6FBC2A2BA048EB3D6AA0@DB7PR10MB2154.EURPRD10.PROD.OUTLOOK.COM">
<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>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
Stuart,</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);">
You are willing to sacrifice the good of the community for a
personal attack against me. Regarding what you wrote: do you
know how many compute time is wasted for all the current DDoS
attacks that this solution will not resolve ? do you know how
many costs involved for organizations and companies which are
under DDoS attacks ? when you compare the current to the state
of this solution then this solution is by far better than the
current state.</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);">
Respectfully,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
Elad<br>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b> Stuart
Willet (primary) <a class="moz-txt-link-rfc2396E" href="mailto:stu@safehosts.co.uk"><stu@safehosts.co.uk></a><br>
<b>Sent:</b> Thursday, April 30, 2020 11:39 PM<br>
<b>To:</b> Elad Cohen <a class="moz-txt-link-rfc2396E" href="mailto:elad@netstyle.io"><elad@netstyle.io></a>;
<a class="moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net">members-discuss@ripe.net</a> <a class="moz-txt-link-rfc2396E" href="mailto:members-discuss@ripe.net"><members-discuss@ripe.net></a><br>
<b>Subject:</b> RE: 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>
<style>
<!--
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif}
a:link, span.x_MsoHyperlink
{color:#0563C1;
text-decoration:underline}
a:visited, span.x_MsoHyperlinkFollowed
{color:#954F72;
text-decoration:underline}
p
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif}
p.x_msonormal0, li.x_msonormal0, div.x_msonormal0
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif}
span.x_EmailStyle19
{font-family:"Calibri",sans-serif;
color:#1F497D}
.x_MsoChpDefault
{font-size:10.0pt}
@page WordSection1
{margin:72.0pt 72.0pt 72.0pt 72.0pt}
div.x_WordSection1
{}
-->
</style>
<div link="#0563C1" vlink="#954F72" lang="EN-GB">
<div class="x_WordSection1">
<p class="x_MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri",sans-serif; color:#1F497D">In
fairness, I couldn�t even be bothered reading further than
the worlds BGP routers needing a firmware update to DOUBLE
packet count whilst adding compute time at an individual
packet level.</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri",sans-serif; color:#1F497D">Another
idea, slightly marred by the unfathomable costs involved,
along with its logistic impossibility.</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri",sans-serif; color:#1F497D">�</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri",sans-serif; color:#1F497D">/me
sits back and grabs the popcorn�..</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri",sans-serif; color:#1F497D">�</span></p>
<div>
<div style="border:none; border-top:solid #E1E1E1 1.0pt;
padding:3.0pt 0cm 0cm 0cm">
<p class="x_MsoNormal"><b><span style="font-size:11.0pt;
font-family:"Calibri",sans-serif"
lang="EN-US">From:</span></b><span
style="font-size:11.0pt;
font-family:"Calibri",sans-serif"
lang="EN-US"> members-discuss
[<a class="moz-txt-link-freetext" href="mailto:members-discuss-bounces@ripe.net">mailto:members-discuss-bounces@ripe.net</a>]
<b>On Behalf Of </b>Elad Cohen<br>
<b>Sent:</b> 30 April 2020 21:31<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net">members-discuss@ripe.net</a><br>
<b>Subject:</b> [members-discuss] Technical solution
to resolve Spoofed IP traffic, Spoofed amplification
DDoS attacks, BGP&RIR hijacking, IoT botnet
infections and Botnet C&Cs</span></p>
</div>
</div>
<p class="x_MsoNormal">�</p>
<div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">Hello Ripe Members!</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">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.
</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">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)</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">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.</span></p>
</div>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">The Process:</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">In the new tracking ip packet there
will be a new transport layer protocol (tracking
protocol) with the following fields:</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">AS number of source BGP router in clear
text</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">AS number of source BGP router
encrypted with the private key of the source BGP
router</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">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':</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">If 'off' then the destination BGP
router will drop that 'tracking ip packet'</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">If 'on' then the destination BGP router
will decrypt the 'encrypted AS number' with the
public key of the specific AS number</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">and after decryption the AS number need
to be the result:</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">if not then to drop the tracking ip
packet and the original ip packet related to it</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">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)</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">More Aspects:</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- Each BGP router will have all the
public keys (of all the ASN's) locally.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">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'):</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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)</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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).</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">'Check tracking flag' in BGP Routers:</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- The ICANN backend infrastructure
through the session with the BGP router - will be
able to set the boolean value of the 'Check tracking
flag'.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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'</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">Automatic preventation of IoT botnet
infections:</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">Automatic prevention of botnet C&C
ip addresses:</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- Botnets C&C are also a problem in
the internet.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">- 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">Respectfully,</span></p>
</div>
<div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">Elad</span></p>
</div>
</div>
<p class="x_MsoNormal"><span
style="font-family:"Calibri",sans-serif;
color:black">�</span></p>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
members-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net">members-discuss@ripe.net</a>
<a class="moz-txt-link-freetext" href="https://lists.ripe.net/mailman/listinfo/members-discuss">https://lists.ripe.net/mailman/listinfo/members-discuss</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi">https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi</a>
</pre>
</blockquote>
</body>
</html>