<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>1. BGP routers are no IPS devices.</p>
<p>2. BGP routers have better things to do than doing crypto-stuff
on a massive scale</p>
<p>3. at this point I suspected a joke (ok, the rest of the mail is
just hilarious):</p>
<p>
<blockquote type="cite">- 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.</blockquote>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Am 30.04.20 um 22:30 schrieb Elad
Cohen:<br>
</div>
<blockquote type="cite"
cite="mid:DB7PR10MB215419AC8F5836BFB583B14ED6AA0@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);">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt">
<span>Hello Ripe Members!</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt">
<span>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.<br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt">
<span>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.
<br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt">
<span>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.<br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt">
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)<br>
<span></span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt">
<span></span><br>
<div>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.</div>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt">
<br>
<div>The Process:<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>In the new tracking ip packet there will be a new
transport layer protocol (tracking protocol) with the
following fields:<br>
</div>
<div>AS number of source BGP router in clear text<br>
</div>
<div>AS number of source BGP router encrypted with the private
key of the source BGP router<br>
</div>
<div><br>
</div>
<div>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':<br>
</div>
<div>If 'off' then the destination BGP router will drop that
'tracking ip packet'<br>
</div>
<div><br>
</div>
<div>If 'on' then the destination BGP router will decrypt the
'encrypted AS number' with the public key of the specific AS
number<br>
</div>
<div>and after decryption the AS number need to be the result:<br>
</div>
<div>if not then to drop the tracking ip packet and the
original ip packet related to it<br>
</div>
<div>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)<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>More Aspects:<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div>- 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.<br>
</div>
<div>- Each BGP router will have all the public keys (of all
the ASN's) locally.<br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>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'):<br>
</div>
<div><br>
</div>
<div>- 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)<br>
</div>
<div>- 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.<br>
</div>
<div>- 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.<br>
</div>
<div>- 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).<br>
</div>
<div>- 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.<br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>'Check tracking flag' in BGP Routers:<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div>- The ICANN backend infrastructure through the session
with the BGP router - will be able to set the boolean value
of the 'Check tracking flag'.<br>
</div>
<div>- 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.<br>
</div>
<div>- 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'<br>
</div>
<div>- 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.<br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Automatic preventation of IoT botnet infections:<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div>- 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.<br>
</div>
<div>- 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.<br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Automatic prevention of botnet C&C ip addresses:<br>
</div>
<div><br>
</div>
<div>- Botnets C&C are also a problem in the internet.<br>
</div>
<div>- 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.<br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Respectfully,</div>
<div>Elad<br>
</div>
</div>
<br>
</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/matthias%40brumm.net">https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Unser Familien-Blog: <a class="moz-txt-link-freetext" href="https://brumm.family">https://brumm.family</a></pre>
</body>
</html>