<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Dear all,</p>
<p>May I remind you what the purpose of this list is?</p>
<p>> This is a list for RIPE NCC members to discuss
**membership-related issues.**</p>
<p>I find myself wondering if my understanding of the definition of
"membership-related issues" is somehow flawed. It would appear
that this list was turned into a media for distributing political
speeches in order to get votes in the upcoming elections.<br>
</p>
<p><br>
</p>
<p>Quoting RIPE Mailing List Code of Conduct here:</p>
<p>> RIPE community members **should not spam mailing lists**,
post others' personal information, register multiple accounts to
avoid moderation or mislead participants, impersonate others, or
make threats. **Overt marketing or promotional activities are
discouraged.**<br>
</p>
<p>I would like to point out that the discussions of the past few
days are - at least, according to my interpretation - in direct
violation of several of the aforementioned rules.<br>
</p>
<p>> Chairs are responsible for facilitating and moderating the
RIPE community's discussions. At times they may direct an
individual to cease a certain type of behaviour. Chairs have the
authority to moderate or ban disruptive community members if they
decide this is necessary.</p>
<p>As such, I would like to request the relevant Chair (I wasn't
able to find out who that is) to step in and moderate the list
properly please! Enough is enough.<br>
</p>
<p>Thank you very much.</p>
<p>Best Regards,<br>
Filip Hruška</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 4/30/20 10:57 PM, Cynthia Revström
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKw1M3O0tLuHqEBS28T--m8XEzFqq7zHQgq1ruPSBW9WimPqng@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Please no more "technical solutions" on
members-discuss!
<div><br>
</div>
<div>- Cynthia</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 30, 2020 at 10:31
PM Elad Cohen <<a href="mailto:elad@netstyle.io"
moz-do-not-send="true">elad@netstyle.io</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<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>
</div>
_______________________________________________<br>
members-discuss mailing list<br>
<a href="mailto:members-discuss@ripe.net" target="_blank"
moz-do-not-send="true">members-discuss@ripe.net</a><br>
<a
href="https://lists.ripe.net/mailman/listinfo/members-discuss"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.ripe.net/mailman/listinfo/members-discuss</a><br>
Unsubscribe: <a
href="https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re</a><br>
</blockquote>
</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/fhr%40fhrnet.eu">https://lists.ripe.net/mailman/options/members-discuss/fhr%40fhrnet.eu</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Filip Hruska
Linux System Administrator</pre>
</body>
</html>