From ds at schallert.com Thu Apr 2 08:02:44 2020 From: ds at schallert.com (Dominic Schallert) Date: Thu, 2 Apr 2020 08:02:44 +0200 Subject: [members-discuss] RPKI ROAs for sponsored resources got deleted? Message-ID: Hello Community, what happened to RPKI ROAs for Sponsored Resources yesterday? All of a sudden, all ROAs for Sponsored Resources got deleted... 2020-04-01 16:16:41 system Updated ROA configuration. Additions: none. Deletions: [asn=ASxxx, prefix=x.x.x.x/22, maximumLength=22]. 2020-04-01 16:16:41 system Updated suppressed routes for ROA alerts. Additions: none. Deletions: [asn=ASxxx, prefix=x.x.x.x/22]. Not only our customers affected but also others. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From johan.hedberg at citynetwork.eu Thu Apr 2 09:14:34 2020 From: johan.hedberg at citynetwork.eu (Johan Hedberg) Date: Thu, 2 Apr 2020 09:14:34 +0200 Subject: [members-discuss] RPKI ROAs for sponsored resources got deleted? In-Reply-To: References: Message-ID: <708D6EC3-C0DF-41BC-A686-C3C97FEAC5D6@citynetwork.eu> Same thing has happened to me too, thanks for bringing it up, I wouldn?t have noticed otherwise. There?s been no routing changes on my end, and those ROA?s were perfectly valid. 2020-04-01 16:17:03 system Updated ROA configuration. Additions: none. Deletions: [asn=AS8949, prefix=2001:67c:560::/48, maximumLength=48], [asn=AS8949, prefix=2001:67c:7bc::/48, maximumLength=48]. 2020-04-01 16:17:03 system Updated suppressed routes for ROA alerts. Additions: none. Deletions: [asn=AS8949, prefix=2001:67c:560::/48], [asn=AS8949, prefix=2001:67c:7bc::/48]. ? Johan Hedberg Senior Systems Engineer Mobile: +46 708 474186 www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED > On 2 Apr 2020, at 08:02, Dominic Schallert wrote: > > Hello Community, > > what happened to RPKI ROAs for Sponsored Resources yesterday? All of a sudden, all ROAs for Sponsored Resources got deleted... > > 2020-04-01 16:16:41 system Updated ROA configuration. Additions: none. Deletions: [asn=ASxxx, prefix=x.x.x.x/22, maximumLength=22]. > 2020-04-01 16:16:41 system Updated suppressed routes for ROA alerts. Additions: none. Deletions: [asn=ASxxx, prefix=x.x.x.x/22]. > > Not only our customers affected but also others. > > Thanks > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/jh%40citynetwork.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.steiner at nemox.net Thu Apr 2 09:35:43 2020 From: r.steiner at nemox.net (Rudolf E. Steiner) Date: Thu, 2 Apr 2020 09:35:43 +0200 Subject: [members-discuss] RPKI ROAs for sponsored resources got deleted? In-Reply-To: References: Message-ID: Dominic Schallert wrote: > what happened to RPKI ROAs for Sponsored Resources yesterday? All of a sudden, all ROAs for Sponsored Resources got deleted... The same here (only "sponsored resources" are affected). -- nemox.net Rudolf E. Steiner r.steiner at nemox.net http://nemox.net/pdat/res/ -------------- next part -------------- A non-text attachment was scrubbed... Name: r_steiner.vcf Type: text/x-vcard Size: 265 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4184 bytes Desc: S/MIME Cryptographic Signature URL: From tore at redpill-linpro.com Thu Apr 2 09:36:01 2020 From: tore at redpill-linpro.com (Tore Anderson) Date: Thu, 2 Apr 2020 09:36:01 +0200 Subject: [members-discuss] RPKI ROAs for sponsored resources got deleted? In-Reply-To: <708D6EC3-C0DF-41BC-A686-C3C97FEAC5D6@citynetwork.eu> References: <708D6EC3-C0DF-41BC-A686-C3C97FEAC5D6@citynetwork.eu> Message-ID: <7369fb3e-0393-7cc7-a2a5-b6f814c05993@redpill-linpro.com> Same here. Someone at the NCC is probably wearning a dunce cap today... 2020-04-01 16:16:39 system Updated ROA configuration. Additions: none. Deletions: [asn=AS2116, prefix=195.88.54.0/23, maximumLength=24], [asn=AS2116, prefix=2001:67c:21e0::/48, maximumLength=48], [asn=AS39029, prefix=195.88.54.0/23, maximumLength=24], [asn=AS39029, prefix=2001:67c:21e0::/48, maximumLength=48]. 2020-04-01 16:16:39 system Updated suppressed routes for ROA alerts. Additions: none. Deletions: [asn=AS2116, prefix=195.88.54.0/23], [asn=AS2116, prefix=2001:67c:21e0::/48], [asn=AS39029, prefix=195.88.54.0/23], [asn=AS39029, prefix=2001:67c:21e0::/48]. Tore * Johan Hedberg > Same thing has happened to me too, thanks for bringing it up, I wouldn?t have noticed otherwise. > > There?s been no routing changes on my end, and those ROA?s were perfectly valid.? > > > 2020-04-01?16:17:03systemUpdated ROA configuration. Additions: none. Deletions: [asn=AS8949, prefix=2001:67c:560::/48,?maximumLength=48], [asn=AS8949, prefix=2001:67c:7bc::/48, maximumLength=48]. > 2020-04-01?16:17:03systemUpdated suppressed routes for ROA alerts. Additions: none. Deletions: [asn=AS8949,?prefix=2001:67c:560::/48], [asn=AS8949, prefix=2001:67c:7bc::/48]. > > ?? > Johan Hedberg > Senior Systems Engineer? > Mobile: +46 708 474186 > > www.citynetwork.eu ?|?www.citycloud.com > > INNOVATION THROUGH OPEN IT?INFRASTRUCTURE > ISO 9001, 14001, 27001, 27015 & 27018?CERTIFIED > >> On 2 Apr 2020, at 08:02, Dominic Schallert > wrote: >> >> Hello Community, >> >> what happened to RPKI ROAs for Sponsored Resources yesterday? All of a sudden, all ROAs for Sponsored Resources got deleted... >> >> 2020-04-01 16:16:41 system Updated ROA configuration. Additions: none. Deletions: [asn=ASxxx, prefix=x.x.x.x/22, maximumLength=22]. >> 2020-04-01 16:16:41 system Updated suppressed routes for ROA alerts. Additions: none. Deletions: [asn=ASxxx, prefix=x.x.x.x/22]. >> >> Not only our customers affected but also others. >> >> Thanks >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/jh%40citynetwork.se > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/tore%40redpill-linpro.com > From thomas at rootsecurity.be Thu Apr 2 09:35:20 2020 From: thomas at rootsecurity.be (Thomas Woidt) Date: Thu, 2 Apr 2020 09:35:20 +0200 Subject: [members-discuss] RPKI ROAs for sponsored resources got deleted? In-Reply-To: <708D6EC3-C0DF-41BC-A686-C3C97FEAC5D6@citynetwork.eu> References: <708D6EC3-C0DF-41BC-A686-C3C97FEAC5D6@citynetwork.eu> Message-ID: We had the same thing happening on our sponsored objects, our own ranges (PA and PI) didnt break. I recreated the ROA's this morning and they are valid again. Looks like some upgrade/change at RIPE going wrong? -- Thomas Woidt Owner https://localitel.as (BelgiumIX.net/Fastic.be) On 02/04/2020 09:14, Johan Hedberg wrote: > Same thing has happened to me too, thanks for bringing it up, I wouldn?t > have noticed otherwise. > > There?s been no routing changes on my end, and those ROA?s were > perfectly valid. > > > 2020-04-01?16:17:03systemUpdated ROA configuration. Additions: none. > Deletions: [asn=AS8949, prefix=2001:67c:560::/48,?maximumLength=48], > [asn=AS8949, prefix=2001:67c:7bc::/48, maximumLength=48]. > 2020-04-01?16:17:03systemUpdated suppressed routes for ROA alerts. > Additions: none. Deletions: [asn=AS8949,?prefix=2001:67c:560::/48], > [asn=AS8949, prefix=2001:67c:7bc::/48]. > > ? > Johan Hedberg > Senior Systems Engineer > Mobile: +46 708 474186 > > www.citynetwork.eu ?| www.citycloud.com > > > INNOVATION THROUGH OPEN IT?INFRASTRUCTURE > ISO 9001, 14001, 27001, 27015 & 27018?CERTIFIED > >> On 2 Apr 2020, at 08:02, Dominic Schallert > > wrote: >> >> Hello Community, >> >> what happened to RPKI ROAs for Sponsored Resources yesterday? All of a >> sudden, all ROAs for Sponsored Resources got deleted... >> >> 2020-04-01 16:16:41 system Updated ROA configuration. Additions: none. >> Deletions: [asn=ASxxx, prefix=x.x.x.x/22, maximumLength=22]. >> 2020-04-01 16:16:41 system Updated suppressed routes for ROA alerts. >> Additions: none. Deletions: [asn=ASxxx, prefix=x.x.x.x/22]. >> >> Not only our customers affected but also others. >> >> Thanks >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: >> https://lists.ripe.net/mailman/options/members-discuss/jh%40citynetwork.se > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/thomas%40rootsecurity.be > From nathalie at ripe.net Thu Apr 2 11:11:12 2020 From: nathalie at ripe.net (Nathalie Trenaman) Date: Thu, 2 Apr 2020 11:11:12 +0200 Subject: [members-discuss] RPKI ROAs for sponsored resources got deleted? In-Reply-To: References: <708D6EC3-C0DF-41BC-A686-C3C97FEAC5D6@citynetwork.eu> Message-ID: <93EC8A71-E251-48B4-A8FD-9799F34BB568@ripe.net> Dear colleagues, Yesterday at 18:17 (UTC+2) we accidentally deleted 4,100 RPKI Route Origin Authorisations (ROAs). These ROAs were related both to members' and sponsored resources. This happened while we were performing maintenance on our internal software. We are currently investigating and we know which ROAs were deleted, which ones are (by now) recreated by users and which ROAs are still missing. We?re currently working on bringing back the missing ROAs and we will inform impacted users when we re-publish their ROAs. Apologies for the inconvenience. Kind regards Nathalie Trenaman Routing Security Programme Manager RIPE NCC > Op 2 apr. 2020, om 09:35 heeft Thomas Woidt het volgende geschreven: > > We had the same thing happening on our sponsored objects, our own ranges (PA and PI) didnt break. > I recreated the ROA's this morning and they are valid again. > > Looks like some upgrade/change at RIPE going wrong? > > > -- > Thomas Woidt > Owner > https://localitel.as > (BelgiumIX.net/Fastic.be) > > > On 02/04/2020 09:14, Johan Hedberg wrote: >> Same thing has happened to me too, thanks for bringing it up, I wouldn?t have noticed otherwise. >> There?s been no routing changes on my end, and those ROA?s were perfectly valid. >> 2020-04-01 16:17:03systemUpdated ROA configuration. Additions: none. Deletions: [asn=AS8949, prefix=2001:67c:560::/48, maximumLength=48], [asn=AS8949, prefix=2001:67c:7bc::/48, maximumLength=48]. >> 2020-04-01 16:17:03systemUpdated suppressed routes for ROA alerts. Additions: none. Deletions: [asn=AS8949, prefix=2001:67c:560::/48], [asn=AS8949, prefix=2001:67c:7bc::/48]. >> ? >> Johan Hedberg >> Senior Systems Engineer >> Mobile: +46 708 474186 >> www.citynetwork.eu | www.citycloud.com >> INNOVATION THROUGH OPEN IT INFRASTRUCTURE >> ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED >>> On 2 Apr 2020, at 08:02, Dominic Schallert > wrote: >>> >>> Hello Community, >>> >>> what happened to RPKI ROAs for Sponsored Resources yesterday? All of a sudden, all ROAs for Sponsored Resources got deleted... >>> >>> 2020-04-01 16:16:41 system Updated ROA configuration. Additions: none. Deletions: [asn=ASxxx, prefix=x.x.x.x/22, maximumLength=22]. >>> 2020-04-01 16:16:41 system Updated suppressed routes for ROA alerts. Additions: none. Deletions: [asn=ASxxx, prefix=x.x.x.x/22]. >>> >>> Not only our customers affected but also others. >>> >>> Thanks >>> _______________________________________________ >>> members-discuss mailing list >>> members-discuss at ripe.net >>> https://lists.ripe.net/mailman/listinfo/members-discuss >>> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/jh%40citynetwork.se >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/thomas%40rootsecurity.be > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/nathalie%40ripe.net From fabiano.d'agostino at cern.ch Thu Apr 16 16:40:05 2020 From: fabiano.d'agostino at cern.ch (Fabiano D'Agostino) Date: Thu, 16 Apr 2020 14:40:05 +0000 Subject: [members-discuss] RIPE Validator v3 error Message-ID: <021BD657244D6343B0850AF5241D26CDD96BD2@CERNXCHG61.cern.ch> Good evening, yesterday I managed to install RIPE Validator v3. Today I rebooted my VM and tried to execute the script again with ./rpki-validator-3.sh, but I get this errors: https://pastebin.com/xtHTCZnq Thanks in advance, Fabiano -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathalie at ripe.net Fri Apr 17 10:19:54 2020 From: nathalie at ripe.net (Nathalie Trenaman) Date: Fri, 17 Apr 2020 10:19:54 +0200 Subject: [members-discuss] RIPE Validator v3 error In-Reply-To: <021BD657244D6343B0850AF5241D26CDD96BD2@CERNXCHG61.cern.ch> References: <021BD657244D6343B0850AF5241D26CDD96BD2@CERNXCHG61.cern.ch> Message-ID: <3B8629AF-7BD1-4FE1-9703-D462C601C26D@ripe.net> Dear Fabiano, As our engineer has discussed with you, this is most likely a configuration error and we'll work with you to resolve it. For these types of cases, the issue can be reported directly to the development team at >. Kind regards, Nathalie K?nneke-Trenaman Routing Security Programme Manager RIPE NCC > Op 16 apr. 2020, om 16:40 heeft Fabiano D'Agostino het volgende geschreven: > > Good evening, > yesterday I managed to install RIPE Validator v3. Today I rebooted my VM and tried to execute the script again with ./rpki-validator-3.sh, but I get this errors: > > https://pastebin.com/xtHTCZnq > > Thanks in advance, > > Fabiano > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/nathalie%40ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From exec-board at ripe.net Wed Apr 22 13:43:31 2020 From: exec-board at ripe.net (Christian Kaufmann) Date: Wed, 22 Apr 2020 13:43:31 +0200 Subject: [members-discuss] Executive Board Decision on Brokers List Message-ID: <31dfdddf-38fc-2c69-d4b8-15bb57001635@ripe.net> Dear colleagues, After analysing all of your comments and weighing the pros and cons of keeping the brokers list on the website, the board has reached a decision. We?ve decided to keep the broker?s list on the website because we think that this list is a valuable resource for our members. However, we will apply stronger due diligence checks and stronger obligations to all brokers in order to prevent abuse. We are currently developing the relevant procedures and legal framework together with the RIPE NCC. We will give you another update when we have more information. Best regards, Christian Kaufmann RIPE NCC Executive Board Chairman From elad at netstyle.io Sat Apr 25 20:20:57 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 18:20:57 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Message-ID: Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296? IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296? IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From noc at xervers.pt Sat Apr 25 20:48:39 2020 From: noc at xervers.pt (noc xervers) Date: Sat, 25 Apr 2020 20:48:39 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: <089e01d61b32$236318a0$6a2949e0$@xervers.pt> That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. NOC xervers | +351 300 404 316 P Please consider the environment before printing this email De: members-discuss Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From br1 at br1.com Sat Apr 25 20:53:09 2020 From: br1 at br1.com (Bruno Cordioli) Date: Sat, 25 Apr 2020 20:53:09 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: Hi Elad, I love your proposal, I would have liked to have heard it some time ago ... 20 years or someone more. But now we have to think about using ipv6, we have no more excuses. We must use IPv6 !!! br1 -- Bruno 'br1' Cordioli www.br1.com br1 at br1.com On Sat, Apr 25, 2020 at 8:36 PM Elad Cohen wrote: > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" > problem (without to upgrade each and every router that exist in the > internet), using the below implementation there will be more 4,294,967,296? > IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination > address are being represented each by four bytes, each of these four bytes > are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: > four bytes can also be displayed as [0-65535].[0-65535] (two numbers and > one dot, the two numbers are bigger because in total they also being > represented as four bytes) > > So there can be one set of 4,294,967,296? IPv4 addresses (the one that we > know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of > [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know > if the source address is of the old formatting (IPv4) or of the new > formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip > header can be used, so in case the source address is of IPv4+ or in case > that the destination address is of IPv4+ (or in case that both the source > and destination addresses are of IPv4+) then the reserved bit in the ip > header will be set to 1 , we then also need to know exactly if the source > address is of IPv4+ or not (meaning of IPv4) and if the destination address > is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF > flag if the source address is of IPv4+ (and not marking the DF flag if the > source address is of IPv4) and marking the MF flag if the destination > address is of IPv4+ (and not marking the MF flag if the destination address > is of IPv4), by using the DF and MF bits which are related to fragmentation > (whenever the reserved bit is set to '1') we are losing the ip > fragmentation functionality for any traffic with an IPv4+ address (for > traffic between two IPv4 addresses, the reserved bit is not set to '1' and > hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no > fragmentation will be able to be done with IPv4+ , the current "Path MTU > Discovery" (RFC 1191) is not good for that case because it is using the DF > bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is > marking that the source address is of IPv4+), and also ICMP protocol can be > blocked by routers in the routing path, the solution is to send multiple > udp requests (with fixed known MTU sizes) to the destination address (lets > call it IPv4+ handshake) - the destination address may or may not receive > them (in case a router in the routing path have multiple upstreams and > wasn't upgraded to an upper version that supports IPv4+ then it will not > recognize the reserved bit and the DF and MF bits related to it, it will > not recognize the new IPv4+ addresses and even if the reserved bit is set > to '1' and MF flag is set to '1' in the ip packet - it will route to to the > destination address just like it is an IPv4 address and not IPv4+ address, > meaning to a completely different destination address) - in case the > destination address indeed received the IPv4+ packets - it will send back > the udp requests to the source address at the exact same sizes (with the > reserved bit flag set to '1' and with the DF and MF flags set accordingly) > - when the source address will receive them - the source address will know > that the destination address is supporting IPv4+ , that ip packets with new > IPv4+ formatting will reach the destination and the source address will > know what is the biggest size of the udp request that was received - and it > will be the MTU for that specific connection between the source and the > destination addresses (The IPv4+ handshake will be done again if there is > no response from the destination after the initial udp handshake was > already completed successfully). > > The udp handshake between a source address and a destination address (that > any of them or them both is an IPv4+ address) will use a specific udp port, > an availalbe unassigned port between 0 to 1023, an operating system > networking stack (that was updated for IPv4+ with the operating system > automatic updating system) will know exactly what this udp port is for - > and will react accordingly, the upgraded operating system networking stack > will also check that the destination address (in the IPv4 or in the IPv4+ > format) is set locally in the operating system, before sending the udp > requests back to the source address (if not then the ip packet will be > dropped by the upgraded operating system networking stack). Any operating > system that wasn't upgraded to support IPv4+ - will just drop that kind of > udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not > upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not > adding any new fields to ip packets or using new fields, IPv4+ will not > cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS > / IP-ID / Options in ip header are being used is because we cannot be 100% > sure that the ToS / IP-ID / Options in the ip header will not be changed or > dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and > we don't want to upgrade any router in the world because it is an > impossible mission) - in the ip header ToS is being cleared by some routers > - IP-ID can be changed by NAT routers - Options field is dropped by many > routers, we can trust that the DF and MF flags will not be modified in the > routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to > be patched/upgraded to support IPv4+ which is an impossible mission, > end-users operating systems need to be upgraded (but it can be done simply > using their automatic updating system), BGP routers (and any router with > multiple physical routing paths) will need to have its firmware upgraded to > support IPv4+, any NAT router that will want to use an external IPv4+ > address will need to have its firmware upgraded (any NAT router that will > use an external IPv4 address will not need to have its firmware upgraded, > only the internet devices in the LAN of the NAT router will need to have a > single operating system update in order for them to access IPv4+ addresses > in the internet), any home router (not NAT) or home modem will not need to > have a firmware upgrade and IPv4+ functionality will be transparent to > them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of > one person from each one of the 5 RIRs and from each one of the operating > systems vendors and from each one of the router manufacture vendors. Even > if IPv4+ will be deployed over time, it will not cause the internet to > break (devices that need to be upgraded to IPv4+ and didn't yet will work > exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to > each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be > able to the provided to the LIRs worldwide, if you have any question please > let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/br1%40br1.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sat Apr 25 20:56:12 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 18:56:12 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <089e01d61b32$236318a0$6a2949e0$@xervers.pt> References: , <089e01d61b32$236318a0$6a2949e0$@xervers.pt> Message-ID: It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Visit our website] [Facebook] [Twitter] [TrustPilot] De: members-discuss Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sat Apr 25 20:58:26 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 18:58:26 +0000 Subject: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Message-ID: I never created an RFC and not familiar with the process, but I wanted to discuss IPv4+ with Ripe members as I'm a Ripe LIR. Respectfully, Elad ________________________________ From: info at cowmedia.de Sent: Saturday, April 25, 2020 9:53 PM To: members-discuss at ripe.net Cc: 'noc xervers'; Elad Cohen Subject: AW: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, anyhow this is not the right list to discuss this. You need to create an RfC ? but as IPv6 already exist there is no real chance of implementing this I would say. Michael Von: members-discuss Im Auftrag von noc xervers Gesendet: Samstag, 25. April 2020 20:49 An: 'Elad Cohen' ; members-discuss at ripe.net Betreff: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Das Bild wurde vom Absender entfernt. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Das Bild wurde vom Absender entfernt. Visit our website] [Das Bild wurde vom Absender entfernt. Facebook] [Das Bild wurde vom Absender entfernt. Twitter] [Das Bild wurde vom Absender entfernt. TrustPilot] De: members-discuss Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at quux.de Sat Apr 25 21:06:48 2020 From: lists at quux.de (Jens Link) Date: Sat, 25 Apr 2020 21:06:48 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: (Elad Cohen's message of "Sat, 25 Apr 2020 18:20:57 +0000") References: Message-ID: <877dy3fkqf.fsf@quux.de> Elad Cohen writes: Elad, thanks for your input. Would yo be willing to present your ideas at the upcoming RIPE and IETF meeting? I would very much appreciate it. Thanks Jens > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296? IPv4 addresses that the world needs > so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296? IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case > the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if > the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address > is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we > are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well > (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the > destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not > recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like > it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes > (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting > will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will > be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was > updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or > in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't > upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload > for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in > the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is > dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating > system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router > that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), > any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed > over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/lists%40quux.de > -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | ---------------------------------------------------------------------------- From elad at netstyle.io Sat Apr 25 21:13:19 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 19:13:19 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , <089e01d61b32$236318a0$6a2949e0$@xervers.pt> , Message-ID: My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). Regarding the number of devices: * Any routing device with more than two physical routes * Any BGP router * Any operating system The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen ; noc xervers ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6. If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Image removed by sender. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Image removed by sender. Visit our website] [Image removed by sender. Facebook] [Image removed by sender. Twitter] [Image removed by sender. TrustPilot] De: members-discuss Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 482 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 344 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 344 bytes Desc: image003.jpg URL: From elad at netstyle.io Sat Apr 25 21:15:50 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 19:15:50 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <877dy3fkqf.fsf@quux.de> References: , <877dy3fkqf.fsf@quux.de> Message-ID: Sure. Respectfully, Elad ________________________________ From: members-discuss on behalf of Jens Link Sent: Saturday, April 25, 2020 10:06 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad Cohen writes: Elad, thanks for your input. Would yo be willing to present your ideas at the upcoming RIPE and IETF meeting? I would very much appreciate it. Thanks Jens > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296? IPv4 addresses that the world needs > so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296? IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case > the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if > the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address > is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we > are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well > (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the > destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not > recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like > it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes > (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting > will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will > be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was > updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or > in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't > upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload > for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in > the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is > dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating > system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router > that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), > any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed > over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/lists%40quux.de > -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | ---------------------------------------------------------------------------- _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/elad%40netstyle.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Sat Apr 25 21:01:39 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Sat, 25 Apr 2020 19:01:39 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , <089e01d61b32$236318a0$6a2949e0$@xervers.pt> Message-ID: Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6. If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Image removed by sender. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Image removed by sender. Visit our website] [Image removed by sender. Facebook] [Image removed by sender. Twitter] [Image removed by sender. TrustPilot] De: members-discuss Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 482 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 344 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 344 bytes Desc: image003.jpg URL: From stu at safehosts.co.uk Sat Apr 25 21:20:41 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Sat, 25 Apr 2020 19:20:41 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , <089e01d61b32$236318a0$6a2949e0$@xervers.pt> , Message-ID: <32db0e46cf874f11bf9b916a647c0566@safehosts.co.uk> Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. What about all the L3 switches and routers not owned by ISP's? What about bigger ISP's ad Tier 1's? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 25 April 2020 20:13 To: Stuart Willet (primary) ; noc xervers ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). Regarding the number of devices: * Any routing device with more than two physical routes * Any BGP router * Any operating system The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6. If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Image removed by sender. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Image removed by sender. Visit our website] [Image removed by sender. Facebook] [Image removed by sender. Twitter] [Image removed by sender. TrustPilot] De: members-discuss > Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 482 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 344 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 344 bytes Desc: image003.jpg URL: From elad at netstyle.io Sat Apr 25 21:21:58 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 19:21:58 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , Message-ID: Thank you very much! I'm not against IPv6, but IPv6 transition will not be completed tomorrow and the current demand from companies and organizations worldwide is for IPv4 and not IPv6, I believe that IPv4+ will make the transition to IPv6 faster. Respectfully, Elad ________________________________ From: Bruno Cordioli Sent: Saturday, April 25, 2020 9:53 PM To: Elad Cohen Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi Elad, I love your proposal, I would have liked to have heard it some time ago ... 20 years or someone more. But now we have to think about using ipv6, we have no more excuses. We must use IPv6 !!! br1 -- Bruno 'br1' Cordioli www.br1.com br1 at br1.com On Sat, Apr 25, 2020 at 8:36 PM Elad Cohen > wrote: Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296? IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296? IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/br1%40br1.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From campbell at inca.ie Sat Apr 25 21:24:48 2020 From: campbell at inca.ie (Ed Campbell) Date: Sat, 25 Apr 2020 20:24:48 +0100 Subject: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: <40375CEC-5F22-4ADC-980A-7353D21DC14D@inca.ie> IPv4 is just over allocated and mismanaged from its inception. Allocating /8?s to DoD etc was just a bad idea. While I like your idea, the problem with it would be to get the likes of Microsoft to develop their stack to recognise it. The learning curve for dumb IT resellers would also be huge. The obvious solution is to force the adoption of IPv6 rather than go through another process that will also end up in exhaustion. It may have taken 20 years or so to exhaust IPv4, but the majority of those years weren?t influenced by 4G and now 5G where the demand is going to be extreme. IPv6 is the clear way. Cheer, Ed Sent from my iPhone > On 25 Apr 2020, at 20:01, Elad Cohen wrote: > > ? > I never created an RFC and not familiar with the process, but I wanted to discuss IPv4+ with Ripe members as I'm a Ripe LIR. > > Respectfully, > Elad > > > From: info at cowmedia.de > Sent: Saturday, April 25, 2020 9:53 PM > To: members-discuss at ripe.net > Cc: 'noc xervers'; Elad Cohen > Subject: AW: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hi, > > anyhow this is not the right list to discuss this. You need to create an RfC ? but as IPv6 already exist there is no real chance of implementing this I would say. > > Michael > > Von: members-discuss Im Auftrag von noc xervers > Gesendet: Samstag, 25. April 2020 20:49 > An: 'Elad Cohen' ; members-discuss at ripe.net > Betreff: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sat Apr 25 21:30:53 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 19:30:53 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <32db0e46cf874f11bf9b916a647c0566@safehosts.co.uk> References: , <089e01d61b32$236318a0$6a2949e0$@xervers.pt> , , <32db0e46cf874f11bf9b916a647c0566@safehosts.co.uk> Message-ID: Please see what I wrote, any home-router (without external NAT IPv4+ address) and any home-modem will not need to be updated, IPv4+ will work fine with them and will be transparent to them, non-technical end-users will not need to update anything, IPv4+ is using transparent adjustment to IPv4 packets and that kind of devices (home router without external NAT IPv4+ address, home modem and any routing equipment with no more than two physical routers - will not need to be updated). The update to all the end-users operating systems will be automatic, routers not owned by ISP's are home-routers as companies with routers have IT support (home routers will not need to be updated). NTT or Telia have millions of routers ? (I'm not sure about it) , any ISP that will receive pressure from his end-users (that their operating system was already upgraded through automatic update system) why the end-user cannot access a IPv4+ site will cause the ISP to update (if didn't update yet). And regarding the /21 - bigger ISP's with more routing devices to update will be able to receive more IPv4+ addresses, there will be more than 4 billion new IPv4 addresses. Even after big amount will be shared between the operating system vendors and the many ASN's - the 5 RIR's will have a huge amount of new IPv4 addresses (more than 800,000,000 per RIR). Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Saturday, April 25, 2020 10:20 PM To: Elad Cohen ; noc xervers ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. What about all the L3 switches and routers not owned by ISP?s? What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 25 April 2020 20:13 To: Stuart Willet (primary) ; noc xervers ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). Regarding the number of devices: * Any routing device with more than two physical routes * Any BGP router * Any operating system The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6. If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Image removed by sender. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Image removed by sender. Visit our website] [Image removed by sender. Facebook] [Image removed by sender. Twitter] [Image removed by sender. TrustPilot] De: members-discuss > Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 482 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 344 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 344 bytes Desc: image003.jpg URL: From a.naveed at go.com.sa Sat Apr 25 21:30:01 2020 From: a.naveed at go.com.sa (Atif Naveed) Date: Sat, 25 Apr 2020 19:30:01 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <32db0e46cf874f11bf9b916a647c0566@safehosts.co.uk> References: , <089e01d61b32$236318a0$6a2949e0$@xervers.pt> , <32db0e46cf874f11bf9b916a647c0566@safehosts.co.uk> Message-ID: Dear Stuart, Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. And I can understand deployment will be not that's straight forward but once it starts flying it will make its own path . Regards Atif Naveed Sr. Specialist IGW/ISP Core Network Operations D:+966-11511-1263 E:a.naveed at go.com.sa www.go.com.sa From: members-discuss On Behalf Of Stuart Willet (primary) Sent: Saturday, April 25, 2020 10:21 PM To: Elad Cohen ; noc xervers ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. What about all the L3 switches and routers not owned by ISP's? What about bigger ISP's ad Tier 1's? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 25 April 2020 20:13 To: Stuart Willet (primary) >; noc xervers >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). Regarding the number of devices: * Any routing device with more than two physical routes * Any BGP router * Any operating system The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6. If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Image removed by sender. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Image removed by sender. Visit our website] [Image removed by sender. Facebook] [Image removed by sender. Twitter] [Image removed by sender. TrustPilot] De: members-discuss > Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 482 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 344 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 344 bytes Desc: image003.jpg URL: From torbjorn.eklov at interlan.se Sat Apr 25 21:36:19 2020 From: torbjorn.eklov at interlan.se (=?utf-8?B?VG9yYmrDtnJuIEVrbMO2dg==?=) Date: Sat, 25 Apr 2020 19:36:19 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <089e01d61b32$236318a0$6a2949e0$@xervers.pt> Message-ID: Stuart, More IPv4 will not make the transition faster. If you and other have equipment that can?t be upgraded and support IPv6 its probably to old for IPv4 upgrade also and with all security issues they can?t be patched for. The OS upgrade for some mix with IPv4+ is a bigger issue than IPv6 deployment. There are billions of hosts/homerouters/IoT that never will get an upgrade to support that. /T > On 25 Apr 2020, at 21:13, Elad Cohen wrote: > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se From elad at netstyle.io Sat Apr 25 21:37:31 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 19:37:31 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , <089e01d61b32$236318a0$6a2949e0$@xervers.pt> , <32db0e46cf874f11bf9b916a647c0566@safehosts.co.uk>, Message-ID: Atif, Regarding what you wrote that deployment will not be straight forward, the deployment of the solution can be very fast, a round table of 50 people (each representing another RIR and operating system vendor and routing equipment manufacturer) - each will receive an amount of IPv4+ addresses, each ISP and ASN will also receive an amount of IPv4+ addresses. Once the operating systems will be updated - there will be pressure from end-users to ISP's why specific IPv4+ site is not loading and then any routing equipment in the routing path that wasn't upgraded will be upgraded (ASN's will receive IPv4+ addresses to upgrade their routing equipment quickly, for example X number of ip addresses if upgrade is up to one month, half of X number of ip addresses if upgrade is up to two months, double the amount of X number of ip addresses if upgrade is in one week, for example. The 'udp handshake' method can be used to know if any router of an ASN was upgraded IPv4+ or not and based on it to measure and to provide to the ASN operator the specific number of IPv4+ addresses). Respectfully, Elad ________________________________ From: Atif Naveed Sent: Saturday, April 25, 2020 10:30 PM To: Stuart Willet (primary) ; Elad Cohen ; noc xervers ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Dear Stuart, Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own path . Regards Atif Naveed Sr. Specialist IGW/ISP Core Network Operations D:+966-11511-1263 E:a.naveed at go.com.sa www.go.com.sa From: members-discuss On Behalf Of Stuart Willet (primary) Sent: Saturday, April 25, 2020 10:21 PM To: Elad Cohen ; noc xervers ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. What about all the L3 switches and routers not owned by ISP?s? What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 25 April 2020 20:13 To: Stuart Willet (primary) >; noc xervers >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). Regarding the number of devices: * Any routing device with more than two physical routes * Any BGP router * Any operating system The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6. If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Image removed by sender. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Image removed by sender. Visit our website] [Image removed by sender. Facebook] [Image removed by sender. Twitter] [Image removed by sender. TrustPilot] De: members-discuss > Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 482 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 344 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 344 bytes Desc: image003.jpg URL: From elad at netstyle.io Sat Apr 25 21:42:08 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 19:42:08 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <089e01d61b32$236318a0$6a2949e0$@xervers.pt> , Message-ID: Torbjorn, Equipment which is old enough not to support IPv6+ will probably won't be able to be upgraded to IPv4+ , but it is still using an IPv4 address, and it is the main point, it is using IPv4 address and there is a global need for IPv4 addresses. Regarding homerouters and iot that you wrote - they will not need to be upgraded to IPv4+ , IPv4+ will be transparent to them. Hosts will be upgraded using the automatic update mechanism of their operating system. Respectfully, Elad ________________________________ From: Torbj?rn Ekl?v Sent: Saturday, April 25, 2020 10:36 PM To: Elad Cohen Cc: Stuart Willet (primary) ; noc xervers ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, More IPv4 will not make the transition faster. If you and other have equipment that can?t be upgraded and support IPv6 its probably to old for IPv4 upgrade also and with all security issues they can?t be patched for. The OS upgrade for some mix with IPv4+ is a bigger issue than IPv6 deployment. There are billions of hosts/homerouters/IoT that never will get an upgrade to support that. /T > On 25 Apr 2020, at 21:13, Elad Cohen wrote: > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at fiberdirekt.se Sat Apr 25 21:46:34 2020 From: peter at fiberdirekt.se (Peter Linder) Date: Sat, 25 Apr 2020 21:46:34 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: Sorry, that won't work. The idea of borrowing more address space bits from various fields in the ip header is not new. None of these ideas, except NAT, has worked, typically because they required a coordinated upgrade effort which is impossible for more reasons than one. As a workaround, people instead agreed to expand the address fields to 128 bits and use the "version" field in the header to differentiate between the old protocol (version set to 4) and the new (version set to 6). I suggest we just use that. Most of the upgrade effort has been completed already. Den 4/25/2020 kl. 8:20 PM, skrev Elad Cohen: > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 > Exhaustion" problem (without to upgrade each and every router that > exist in the internet), using the below implementation there will be > more 4,294,967,296? IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination > address are being represented each by four bytes, each of these four > bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: > four bytes can also be displayed as [0-65535].[0-65535] (two numbers > and one dot, the two numbers are bigger because in total they also > being represented as four bytes) > > So there can be one set of 4,294,967,296? IPv4 addresses (the one that > we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of > [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to > know if the source address is of the old formatting (IPv4) or of the > new formatting (lets call it IPv4+), for that mark the 'reserved bit' > in the ip header can be used, so in case the source address is of > IPv4+ or in case that the destination address is of IPv4+ (or in case > that both the source and destination addresses are of IPv4+) then the > reserved bit in the ip header will be set to 1 , we then also need to > know exactly if the source address is of IPv4+ or not (meaning of > IPv4) and if the destination address is of IPv4+ or not (meaning of > IPv4) - this can be done by marking the DF flag if the source address > is of IPv4+ (and not marking the DF flag if the source address is of > IPv4) and marking the MF flag if the destination address is of IPv4+ > (and not marking the MF flag if the destination address is of IPv4), > by using the DF and MF bits which are related to fragmentation > (whenever the reserved bit is set to '1') we are losing the ip > fragmentation functionality for any traffic with an IPv4+ address (for > traffic between two IPv4 addresses, the reserved bit is not set to '1' > and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because > no fragmentation will be able to be done with IPv4+ , the current > "Path MTU Discovery" (RFC 1191) is not good for that case because it > is using the DF bit which we are using as well (and in IPv4+ traffic a > DF flag set to 1 is marking that the source address is of IPv4+), and > also ICMP protocol can be blocked by routers in the routing path, the > solution is to send multiple udp requests (with fixed known MTU sizes) > to the destination address (lets call it IPv4+ handshake) - the > destination address may or may not receive them (in case a router in > the routing path have multiple upstreams and wasn't upgraded to an > upper version that supports IPv4+ then it will not recognize the > reserved bit and the DF and MF bits related to it, it will not > recognize the new IPv4+ addresses and even if the reserved bit is set > to '1' and MF flag is set to '1' in the ip packet - it will route to > to the destination address just like it is an IPv4 address and not > IPv4+ address, meaning to a completely different destination address) > - in case the destination address indeed received the IPv4+ packets - > it will send back the udp requests to the source address at the exact > same sizes (with the reserved bit flag set to '1' and with the DF and > MF flags set accordingly) - when the source address will receive them > - the source address will know that the destination address is > supporting IPv4+ , that ip packets with new IPv4+ formatting will > reach the destination and the source address will know what is the > biggest size of the udp request that was received - and it will be the > MTU for that specific connection between the source and the > destination addresses (The IPv4+ handshake will be done again if there > is no response from the destination after the initial udp handshake > was already completed successfully). > > The udp handshake between a source address and a destination address > (that any of them or them both is an IPv4+ address) will use a > specific udp port, an availalbe unassigned port between 0 to 1023, an > operating system networking stack (that was updated for IPv4+ with the > operating system automatic updating system) will know exactly what > this udp port is for - and will react accordingly, the upgraded > operating system networking stack will also check that the destination > address (in the IPv4 or in the IPv4+ format) is set locally in the > operating system, before sending the udp requests back to the source > address (if not then the ip packet will be dropped by the upgraded > operating system networking stack). Any operating system that wasn't > upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was > not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is > also not adding any new fields to ip packets or using new fields, > IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the > ToS / IP-ID / Options in ip header are being used is because we cannot > be 100% sure that the ToS / IP-ID / Options in the ip header will not > be changed or dropped by any rouer in the routing path that wasn't > upgraded to IPv4+ (and we don't want to upgrade any router in the > world because it is an impossible mission) - in the ip header ToS is > being cleared by some routers - IP-ID can be changed by NAT routers - > Options field is dropped by many routers, we can trust that the DF and > MF flags will not be modified in the routing path by routers that > weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs > to be patched/upgraded to support IPv4+ which is an impossible > mission, end-users operating systems need to be upgraded (but it can > be done simply using their automatic updating system), BGP routers > (and any router with multiple physical routing paths) will need to > have its firmware upgraded to support IPv4+, any NAT router that will > want to use an external IPv4+ address will need to have its firmware > upgraded (any NAT router that will use an external IPv4 address will > not need to have its firmware upgraded, only the internet devices in > the LAN of the NAT router will need to have a single operating system > update in order for them to access IPv4+ addresses in the internet), > any home router (not NAT) or home modem will not need to have a > firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round > table of one person from each one of the 5 RIRs and from each one of > the operating systems vendors and from each one of the router > manufacture vendors. Even if IPv4+ will be deployed over time, it will > not cause the internet to break (devices that need to be upgraded to > IPv4+ and didn't yet will work exactly as they are now with IPv4, they > will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to > each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that > will be able to the provided to the LIRs worldwide, if you have any > question please let me know. > > Respectfully, > Elad > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/peter%40fiberdirekt.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From radu.anghel at xindi.eu Sat Apr 25 21:51:12 2020 From: radu.anghel at xindi.eu (Radu Anghel) Date: Sat, 25 Apr 2020 21:51:12 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: Hi Elad, Do you think that if we also display them in HEX (0-FFFF.0-FFFF) we could get double the amout of IPv4+??? Thaaanks! Radu On 25.04.2020 20:20, Elad Cohen wrote: > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" > problem (without to upgrade each and every router that exist in the > internet), using the below implementation there will be more > 4,294,967,296? IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination > address are being represented each by four bytes, each of these four > bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: > four bytes can also be displayed as [0-65535].[0-65535] (two numbers and > one dot, the two numbers are bigger because in total they also being > represented as four bytes) > > So there can be one set of 4,294,967,296? IPv4 addresses (the one that > we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of > [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to > know if the source address is of the old formatting (IPv4) or of the new > formatting (lets call it IPv4+), for that mark the 'reserved bit' in the > ip header can be used, so in case the source address is of IPv4+ or in > case that the destination address is of IPv4+ (or in case that both the > source and destination addresses are of IPv4+) then the reserved bit in > the ip header will be set to 1 , we then also need to know exactly if > the source address is of IPv4+ or not (meaning of IPv4) and if the > destination address is of IPv4+ or not (meaning of IPv4) - this can be > done by marking the DF flag if the source address is of IPv4+ (and not > marking the DF flag if the source address is of IPv4) and marking the MF > flag if the destination address is of IPv4+ (and not marking the MF flag > if the destination address is of IPv4), by using the DF and MF bits > which are related to fragmentation (whenever the reserved bit is set to > '1') we are losing the ip fragmentation functionality for any traffic > with an IPv4+ address (for traffic between two IPv4 addresses, the > reserved bit is not set to '1' and hence optional ip fragment > functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no > fragmentation will be able to be done with IPv4+ , the current "Path MTU > Discovery" (RFC 1191) is not good for that case because it is using the > DF bit which we are using as well (and in IPv4+ traffic a DF flag set to > 1 is marking that the source address is of IPv4+), and also ICMP > protocol can be blocked by routers in the routing path, the solution is > to send multiple udp requests (with fixed known MTU sizes) to the > destination address (lets call it IPv4+ handshake) - the destination > address may or may not receive them (in case a router in the routing > path have multiple upstreams and wasn't upgraded to an upper version > that supports IPv4+ then it will not recognize the reserved bit and the > DF and MF bits related to it, it will not recognize the new IPv4+ > addresses and even if the reserved bit is set to '1' and MF flag is set > to '1' in the ip packet - it will route to to the destination address > just like it is an IPv4 address and not IPv4+ address, meaning to a > completely different destination address) - in case the destination > address indeed received the IPv4+ packets - it will send back the udp > requests to the source address at the exact same sizes (with the > reserved bit flag set to '1' and with the DF and MF flags set > accordingly) - when the source address will receive them - the source > address will know that the destination address is supporting IPv4+ , > that ip packets with new IPv4+ formatting will reach the destination and > the source address will know what is the biggest size of the udp request > that was received - and it will be the MTU for that specific connection > between the source and the destination addresses (The IPv4+ handshake > will be done again if there is no response from the destination after > the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address > (that any of them or them both is an IPv4+ address) will use a specific > udp port, an availalbe unassigned port between 0 to 1023, an operating > system networking stack (that was updated for IPv4+ with the operating > system automatic updating system) will know exactly what this udp port > is for - and will react accordingly, the upgraded operating system > networking stack will also check that the destination address (in the > IPv4 or in the IPv4+ format) is set locally in the operating system, > before sending the udp requests back to the source address (if not then > the ip packet will be dropped by the upgraded operating system > networking stack). Any operating system that wasn't upgraded to support > IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not > upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also > not adding any new fields to ip packets or using new fields, IPv4+ will > not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the > ToS / IP-ID / Options in ip header are being used is because we cannot > be 100% sure that the ToS / IP-ID / Options in the ip header will not be > changed or dropped by any rouer in the routing path that wasn't upgraded > to IPv4+ (and we don't want to upgrade any router in the world because > it is an impossible mission) - in the ip header ToS is being cleared by > some routers - IP-ID can be changed by NAT routers - Options field is > dropped by many routers, we can trust that the DF and MF flags will not > be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs > to be patched/upgraded to support IPv4+ which is an impossible mission, > end-users operating systems need to be upgraded (but it can be done > simply using their automatic updating system), BGP routers (and any > router with multiple physical routing paths) will need to have its > firmware upgraded to support IPv4+, any NAT router that will want to use > an external IPv4+ address will need to have its firmware upgraded (any > NAT router that will use an external IPv4 address will not need to have > its firmware upgraded, only the internet devices in the LAN of the NAT > router will need to have a single operating system update in order for > them to access IPv4+ addresses in the internet), any home router (not > NAT) or home modem will not need to have a firmware upgrade and IPv4+ > functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table > of one person from each one of the 5 RIRs and from each one of the > operating systems vendors and from each one of the router manufacture > vendors. Even if IPv4+ will be deployed over time, it will not cause the > internet to break (devices that need to be upgraded to IPv4+ and didn't > yet will work exactly as they are now with IPv4, they will just not yet > support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to > each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will > be able to the provided to the LIRs worldwide, if you have any question > please let me know. > > Respectfully, > Elad > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/radu.anghel%40xindi.eu > From elad at netstyle.io Sat Apr 25 21:53:02 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 19:53:02 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <089e01d61b32$236318a0$6a2949e0$@xervers.pt> , , Message-ID: Torbjorn, I would like to add one more thing, it is not obvious that any equipment that cannot support IPv6 will not support IPv4+ , and I also believe that it is incorrect because adding a completely new protocol (IPv6+) to a low-resources IoT device (that might not planned initially with additional hardware resources to support a new protocol) is completely different than the IoT device just to handle the exact same number of bits of IPv4 packet - just differently - no additional physical hardware is needed like RAM (and even without an upgrade, the IoT device will work in the internet exactly like is working now). Respectfully, Elad ________________________________ From: Elad Cohen Sent: Saturday, April 25, 2020 10:42 PM To: Torbj?rn Ekl?v Cc: Stuart Willet (primary) ; noc xervers ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Torbjorn, Equipment which is old enough not to support IPv6+ will probably won't be able to be upgraded to IPv4+ , but it is still using an IPv4 address, and it is the main point, it is using IPv4 address and there is a global need for IPv4 addresses. Regarding homerouters and iot that you wrote - they will not need to be upgraded to IPv4+ , IPv4+ will be transparent to them. Hosts will be upgraded using the automatic update mechanism of their operating system. Respectfully, Elad ________________________________ From: Torbj?rn Ekl?v Sent: Saturday, April 25, 2020 10:36 PM To: Elad Cohen Cc: Stuart Willet (primary) ; noc xervers ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, More IPv4 will not make the transition faster. If you and other have equipment that can?t be upgraded and support IPv6 its probably to old for IPv4 upgrade also and with all security issues they can?t be patched for. The OS upgrade for some mix with IPv4+ is a bigger issue than IPv6 deployment. There are billions of hosts/homerouters/IoT that never will get an upgrade to support that. /T > On 25 Apr 2020, at 21:13, Elad Cohen wrote: > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at cowmedia.de Sat Apr 25 20:53:33 2020 From: info at cowmedia.de (info at cowmedia.de) Date: Sat, 25 Apr 2020 20:53:33 +0200 Subject: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <089e01d61b32$236318a0$6a2949e0$@xervers.pt> References: <089e01d61b32$236318a0$6a2949e0$@xervers.pt> Message-ID: <2a7001d61b32$d1ed8f90$75c8aeb0$@cowmedia.de> Hi, anyhow this is not the right list to discuss this. You need to create an RfC ? but as IPv6 already exist there is no real chance of implementing this I would say. Michael Von: members-discuss Im Auftrag von noc xervers Gesendet: Samstag, 25. April 2020 20:49 An: 'Elad Cohen' ; members-discuss at ripe.net Betreff: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. NOC xervers | +351 300 404 316 P Please consider the environment before printing this email De: members-discuss Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 482 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 344 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 344 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5533 bytes Desc: not available URL: From info at cowmedia.de Sat Apr 25 22:00:05 2020 From: info at cowmedia.de (info at cowmedia.de) Date: Sat, 25 Apr 2020 22:00:05 +0200 Subject: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <089e01d61b32$236318a0$6a2949e0$@xervers.pt> , Message-ID: <2bf801d61b3c$1d7edf50$587c9df0$@cowmedia.de> Elad, i really appreciate your idea, but there are unfortunately some issues to this. 1. It requires an additonal header bit that is not part of the address itself, how would a filter know about this when there is only the ip address given (the bit it not available to them). 2. The time of developing and rollout a new type of protocol (what this is) takes years (maybe 10-15 years) even this is theoretically just a small change) 3. Configuring dual protocol is already with IPv4+6 sometimes a hard issue. There are issues with what protocol is the main one and how applications are using them 4. It is not enough to update only networking equipment because the application layer decides about the target (for example the browser via DNS), even today so many software is not compatible with IPv6, how would you expect them to include IPv4+? 5. IPv4+ would slow down IPv6 rollout 6. Your thinking about users will complain when sites are not reachable is not correct. ISPs and service owner make sure right now that the service is at least reachable by IPv4 and they are in the process of trying to add IPv6 to them. There is no way of having users not access any service just because a provider or any MITM is not yet ready. Hence IPv4+ will NEVER be solely rollout to any service. 7. Plus many more points that were raised. You are really 20 years too late. I am so sorry. Michael Von: members-discuss Im Auftrag von Elad Cohen Gesendet: Samstag, 25. April 2020 21:42 An: Torbj?rn Ekl?v Cc: members-discuss at ripe.net Betreff: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Torbjorn, Equipment which is old enough not to support IPv6+ will probably won't be able to be upgraded to IPv4+ , but it is still using an IPv4 address, and it is the main point, it is using IPv4 address and there is a global need for IPv4 addresses. Regarding homerouters and iot that you wrote - they will not need to be upgraded to IPv4+ , IPv4+ will be transparent to them. Hosts will be upgraded using the automatic update mechanism of their operating system. Respectfully, Elad _____ From: Torbj?rn Ekl?v > Sent: Saturday, April 25, 2020 10:36 PM To: Elad Cohen > Cc: Stuart Willet (primary) >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, More IPv4 will not make the transition faster. If you and other have equipment that can?t be upgraded and support IPv6 its probably to old for IPv4 upgrade also and with all security issues they can?t be patched for. The OS upgrade for some mix with IPv4+ is a bigger issue than IPv6 deployment. There are billions of hosts/homerouters/IoT that never will get an upgrade to support that. /T > On 25 Apr 2020, at 21:13, Elad Cohen > wrote: > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss > Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40inte rlan.se -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5533 bytes Desc: not available URL: From elad at netstyle.io Sat Apr 25 22:00:54 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 20:00:54 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , Message-ID: Peter, Please read what I wrote, I checked each and every field (so not every device in the internet will need to be upgraded and zero coordination is needed, anyone can upgrade any device at anytime and nothing will break), using the DF and MF bits (without fragmentation but with MTU) is a solution, it will not cause the internet to break, the "MTU udp handshake" is providing a replacement for the DF and MF bits. Any internet device don't have to be upgraded to IPv4+ , it is possible that an IPv4+ packet will not reach from source to destination (and then udp handshake will know it initially and will not send the IPv4+ packet), and all the routing equipment in the routing path don't have to be upgraded as well (only bgp routers and non-bgp routers with more than two physical routes). Respectfully, Elad ________________________________ From: members-discuss on behalf of Peter Linder Sent: Saturday, April 25, 2020 10:46 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sorry, that won't work. The idea of borrowing more address space bits from various fields in the ip header is not new. None of these ideas, except NAT, has worked, typically because they required a coordinated upgrade effort which is impossible for more reasons than one. As a workaround, people instead agreed to expand the address fields to 128 bits and use the "version" field in the header to differentiate between the old protocol (version set to 4) and the new (version set to 6). I suggest we just use that. Most of the upgrade effort has been completed already. Den 4/25/2020 kl. 8:20 PM, skrev Elad Cohen: Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296? IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296? IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/peter%40fiberdirekt.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Sat Apr 25 22:04:46 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Sat, 25 Apr 2020 20:04:46 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , <089e01d61b32$236318a0$6a2949e0$@xervers.pt> , <32db0e46cf874f11bf9b916a647c0566@safehosts.co.uk> Message-ID: <04aa24ccc25b4f9aa4a34e45381a4d12@safehosts.co.uk> Dear Atif, Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. I'm not sure there is a Tier1 who doesn't offer IPv6. Most UK ISP's now provide IPv6 by default to people's homes. I agree the uptake has been incredibly slow, which is why I don't think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. Why would the uptake be faster for IPv4+? Best, Stuart Willet. From: Atif Naveed [mailto:a.naveed at go.com.sa] Sent: 25 April 2020 20:30 To: Stuart Willet (primary) ; Elad Cohen ; noc xervers ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Dear Stuart, Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. And I can understand deployment will be not that's straight forward but once it starts flying it will make its own path . Regards Atif Naveed Sr. Specialist IGW/ISP Core Network Operations D:+966-11511-1263 E:a.naveed at go.com.sa www.go.com.sa From: members-discuss > On Behalf Of Stuart Willet (primary) Sent: Saturday, April 25, 2020 10:21 PM To: Elad Cohen >; noc xervers >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. What about all the L3 switches and routers not owned by ISP's? What about bigger ISP's ad Tier 1's? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 25 April 2020 20:13 To: Stuart Willet (primary) >; noc xervers >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). Regarding the number of devices: * Any routing device with more than two physical routes * Any BGP router * Any operating system The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6. If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Image removed by sender. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Image removed by sender. Visit our website] [Image removed by sender. Facebook] [Image removed by sender. Twitter] [Image removed by sender. TrustPilot] De: members-discuss > Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 482 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 344 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 344 bytes Desc: image003.jpg URL: From elad at netstyle.io Sat Apr 25 22:05:21 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 20:05:21 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , Message-ID: Radu, That will cause a performance overload on routers and then each and every device on the internet will need to be upgraded - an impossible mission. My solution is feasible, can be very quickly deployed, doesn't require the upgrade of all devices in the internet and will bring to each RIR more than 800,000,000 IPv4 addresses (and will also bring to each ISP and ASN a high amount of free IPv4 addresses). Respectfully, Elad ________________________________ From: members-discuss on behalf of Radu Anghel via members-discuss Sent: Saturday, April 25, 2020 10:51 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi Elad, Do you think that if we also display them in HEX (0-FFFF.0-FFFF) we could get double the amout of IPv4+??? Thaaanks! Radu On 25.04.2020 20:20, Elad Cohen wrote: > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" > problem (without to upgrade each and every router that exist in the > internet), using the below implementation there will be more > 4,294,967,296? IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination > address are being represented each by four bytes, each of these four > bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: > four bytes can also be displayed as [0-65535].[0-65535] (two numbers and > one dot, the two numbers are bigger because in total they also being > represented as four bytes) > > So there can be one set of 4,294,967,296? IPv4 addresses (the one that > we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of > [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to > know if the source address is of the old formatting (IPv4) or of the new > formatting (lets call it IPv4+), for that mark the 'reserved bit' in the > ip header can be used, so in case the source address is of IPv4+ or in > case that the destination address is of IPv4+ (or in case that both the > source and destination addresses are of IPv4+) then the reserved bit in > the ip header will be set to 1 , we then also need to know exactly if > the source address is of IPv4+ or not (meaning of IPv4) and if the > destination address is of IPv4+ or not (meaning of IPv4) - this can be > done by marking the DF flag if the source address is of IPv4+ (and not > marking the DF flag if the source address is of IPv4) and marking the MF > flag if the destination address is of IPv4+ (and not marking the MF flag > if the destination address is of IPv4), by using the DF and MF bits > which are related to fragmentation (whenever the reserved bit is set to > '1') we are losing the ip fragmentation functionality for any traffic > with an IPv4+ address (for traffic between two IPv4 addresses, the > reserved bit is not set to '1' and hence optional ip fragment > functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no > fragmentation will be able to be done with IPv4+ , the current "Path MTU > Discovery" (RFC 1191) is not good for that case because it is using the > DF bit which we are using as well (and in IPv4+ traffic a DF flag set to > 1 is marking that the source address is of IPv4+), and also ICMP > protocol can be blocked by routers in the routing path, the solution is > to send multiple udp requests (with fixed known MTU sizes) to the > destination address (lets call it IPv4+ handshake) - the destination > address may or may not receive them (in case a router in the routing > path have multiple upstreams and wasn't upgraded to an upper version > that supports IPv4+ then it will not recognize the reserved bit and the > DF and MF bits related to it, it will not recognize the new IPv4+ > addresses and even if the reserved bit is set to '1' and MF flag is set > to '1' in the ip packet - it will route to to the destination address > just like it is an IPv4 address and not IPv4+ address, meaning to a > completely different destination address) - in case the destination > address indeed received the IPv4+ packets - it will send back the udp > requests to the source address at the exact same sizes (with the > reserved bit flag set to '1' and with the DF and MF flags set > accordingly) - when the source address will receive them - the source > address will know that the destination address is supporting IPv4+ , > that ip packets with new IPv4+ formatting will reach the destination and > the source address will know what is the biggest size of the udp request > that was received - and it will be the MTU for that specific connection > between the source and the destination addresses (The IPv4+ handshake > will be done again if there is no response from the destination after > the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address > (that any of them or them both is an IPv4+ address) will use a specific > udp port, an availalbe unassigned port between 0 to 1023, an operating > system networking stack (that was updated for IPv4+ with the operating > system automatic updating system) will know exactly what this udp port > is for - and will react accordingly, the upgraded operating system > networking stack will also check that the destination address (in the > IPv4 or in the IPv4+ format) is set locally in the operating system, > before sending the udp requests back to the source address (if not then > the ip packet will be dropped by the upgraded operating system > networking stack). Any operating system that wasn't upgraded to support > IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not > upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also > not adding any new fields to ip packets or using new fields, IPv4+ will > not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the > ToS / IP-ID / Options in ip header are being used is because we cannot > be 100% sure that the ToS / IP-ID / Options in the ip header will not be > changed or dropped by any rouer in the routing path that wasn't upgraded > to IPv4+ (and we don't want to upgrade any router in the world because > it is an impossible mission) - in the ip header ToS is being cleared by > some routers - IP-ID can be changed by NAT routers - Options field is > dropped by many routers, we can trust that the DF and MF flags will not > be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs > to be patched/upgraded to support IPv4+ which is an impossible mission, > end-users operating systems need to be upgraded (but it can be done > simply using their automatic updating system), BGP routers (and any > router with multiple physical routing paths) will need to have its > firmware upgraded to support IPv4+, any NAT router that will want to use > an external IPv4+ address will need to have its firmware upgraded (any > NAT router that will use an external IPv4 address will not need to have > its firmware upgraded, only the internet devices in the LAN of the NAT > router will need to have a single operating system update in order for > them to access IPv4+ addresses in the internet), any home router (not > NAT) or home modem will not need to have a firmware upgrade and IPv4+ > functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table > of one person from each one of the 5 RIRs and from each one of the > operating systems vendors and from each one of the router manufacture > vendors. Even if IPv4+ will be deployed over time, it will not cause the > internet to break (devices that need to be upgraded to IPv4+ and didn't > yet will work exactly as they are now with IPv4, they will just not yet > support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to > each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will > be able to the provided to the LIRs worldwide, if you have any question > please let me know. > > Respectfully, > Elad > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/radu.anghel%40xindi.eu > _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/elad%40netstyle.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From torbjorn.eklov at interlan.se Sat Apr 25 22:12:59 2020 From: torbjorn.eklov at interlan.se (=?utf-8?B?VG9yYmrDtnJuIEVrbMO2dg==?=) Date: Sat, 25 Apr 2020 20:12:59 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <089e01d61b32$236318a0$6a2949e0$@xervers.pt> Message-ID: Elad - Stuart, We try this way - First - Why didn?t you and anyone make this proposition for +10 years ago? This problem was known +20 years ago. Second - It?s to late. It will take more than three years to achieve this with every OS involved. And then it?s to late to make updates for ISP?s who didn?t upgrade their equipment. /Tobbe - end of my discussion PS. I live in Sweden where we only have +4% IPv6 but I hate our CGNAT! > On 25 Apr 2020, at 21:53, Elad Cohen wrote: > > Torbjorn, > > I would like to add one more thing, it is not obvious that any equipment that cannot support IPv6 will not support IPv4+ , and I also believe that it is incorrect because adding a completely new protocol (IPv6+) to a low-resources IoT device (that might not planned initially with additional hardware resources to support a new protocol) is completely different than the IoT device just to handle the exact same number of bits of IPv4 packet - just differently - no additional physical hardware is needed like RAM (and even without an upgrade, the IoT device will work in the internet exactly like is working now). > > Respectfully, > Elad > > From: Elad Cohen > Sent: Saturday, April 25, 2020 10:42 PM > To: Torbj?rn Ekl?v > Cc: Stuart Willet (primary) ; noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Torbjorn, > > Equipment which is old enough not to support IPv6+ will probably won't be able to be upgraded to IPv4+ , but it is still using an IPv4 address, and it is the main point, it is using IPv4 address and there is a global need for IPv4 addresses. > > Regarding homerouters and iot that you wrote - they will not need to be upgraded to IPv4+ , IPv4+ will be transparent to them. > > Hosts will be upgraded using the automatic update mechanism of their operating system. > > Respectfully, > Elad > From: Torbj?rn Ekl?v > Sent: Saturday, April 25, 2020 10:36 PM > To: Elad Cohen > Cc: Stuart Willet (primary) ; noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Stuart, > More IPv4 will not make the transition faster. > If you and other have equipment that can?t be upgraded and support IPv6 its probably to old for IPv4 upgrade also and with all security issues they can?t be patched for. > The OS upgrade for some mix with IPv4+ is a bigger issue than IPv6 deployment. There are billions of hosts/homerouters/IoT that never will get an upgrade to support that. > > /T > > > > On 25 Apr 2020, at 21:13, Elad Cohen wrote: > > > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > > > Regarding the number of devices: > > ? Any routing device with more than two physical routes > > ? Any BGP router > > ? Any operating system > > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > > > Respectfully, > > Elad > > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 10:01 PM > > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > > > Best, > > Stuart Willet. > > > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > > Sent: 25 April 2020 19:56 > > To: noc xervers ; members-discuss at ripe.net > > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > > > switches are working on layer2, they are not related to ip. > > > > Respectfully, > > Elad > > > > From: noc xervers > > Sent: Saturday, April 25, 2020 9:48 PM > > To: Elad Cohen ; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > > It's a better and cleaner solution to move to IPv6. > > > > Cheers. > > > > > > NOC xervers | +351 300 404 316 > > P Please consider the environment before printing this email > > > > > > > > > > De: members-discuss Em Nome De Elad Cohen > > Enviada: s?bado, 25 de abril de 2020 20:21 > > Para: members-discuss at ripe.net > > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > > > Hello Everyone, > > > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > > > Respectfully, > > Elad > > _______________________________________________ > > members-discuss mailing list > > members-discuss at ripe.net > > https://lists.ripe.net/mailman/listinfo/members-discuss > > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se From elad at netstyle.io Sat Apr 25 22:30:11 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 20:30:11 +0000 Subject: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <2bf801d61b3c$1d7edf50$587c9df0$@cowmedia.de> References: <089e01d61b32$236318a0$6a2949e0$@xervers.pt> , , <2bf801d61b3c$1d7edf50$587c9df0$@cowmedia.de> Message-ID: Michael, Please see my following answers: 1. No additional header bit is needed, the ip packet is exactly as it is now, the 'reserved bit flag' will just be '1' instead of '0' , the reserved bit is available in the ip header and hence the filter will see the whole ip packet. (any router that do any check regarding the source address or the destination - will need to be upgraded). 2. This is not a new protocol, IPv6 is a new protocol, it is an adjustment to a current protocol and not any device which implemented that protocol (IPv4) will need to be upgraded, providing IPv4 address (of IPv4+) to all the parties involved (when IPv4 addresses are so much needed in these days) and using the automatic updating mechanism of operating systems - can and will make this whole process much much faster. 3. It is an adjustment to a current protocol and not a completely new protocol, clean code updates will resolve it. There is no need to know what is the main protocol (IPv4+ or IPv4) because the exact same IPv4 packet is being used, upgraded routers will just know how to route it well (if the four bytes of source address are of IPv4 or IPv4+ and if the four bytes of destination address are of IPv4 or IPv4+). 4. Please see what I wrote, I didn't write that only some of the needed routers will be upgraded, I wrote that all the end-users operating systems will be updated (through the automatic updating mechanism of the operating systems). 5. We can argue on it, I believe that if companies and organizations will have a high pool of IPv4 then they will be able to support both IPv6 and IPv4 and then more and more companies and organizations will support both IPv4 and IPv6 until the whole internet will be able to move to only IPv6. IPv6 is being talked for 20 years and currently the world is in a very big problem because of the lack of IPv4. 6. From the very beginning with the round table and IPv4+ addresses incentives to everyone - IPv4+ will be deployed very very fast, I wrote about very margins cases, from the very beginning through the round table IPv4+ will be deployed (Automatic operating system updates will done only after the ISP's and ASN's will complete to update their routers and will receive their amount of free new IPv4 addresses). And just in case an ISP will assign to its user an IPv4+ addresses to use the internet then that IPv4+ addresses need to access the whole internet (there are many online services that are not yet supporting IPv6+). I'm not against IPv6 - I surely believe it is the future, but more IPv4 addresses are needed for and until IPv6 to be fully adapted. 7. Please write about any unanswered point. I don't believe that I'm late because 20 years ago there wasn't any need to use the 'reserved bit flag' in the ip header, it was intended for future use, and what would be a better use to the 'reserved bit flag' than to use it for the current IPv4 Exhaustion problem. Respectfully, Elad ________________________________ From: members-discuss on behalf of info at cowmedia.de Sent: Saturday, April 25, 2020 11:00 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, i really appreciate your idea, but there are unfortunately some issues to this. 1. It requires an additonal header bit that is not part of the address itself, how would a filter know about this when there is only the ip address given (the bit it not available to them). 2. The time of developing and rollout a new type of protocol (what this is) takes years (maybe 10-15 years) even this is theoretically just a small change) 3. Configuring dual protocol is already with IPv4+6 sometimes a hard issue. There are issues with what protocol is the main one and how applications are using them 4. It is not enough to update only networking equipment because the application layer decides about the target (for example the browser via DNS), even today so many software is not compatible with IPv6, how would you expect them to include IPv4+? 5. IPv4+ would slow down IPv6 rollout 6. Your thinking about users will complain when sites are not reachable is not correct. ISPs and service owner make sure right now that the service is at least reachable by IPv4 and they are in the process of trying to add IPv6 to them. There is no way of having users not access any service just because a provider or any MITM is not yet ready. Hence IPv4+ will NEVER be solely rollout to any service. 7. Plus many more points that were raised. You are really 20 years too late. I am so sorry. Michael Von: members-discuss Im Auftrag von Elad Cohen Gesendet: Samstag, 25. April 2020 21:42 An: Torbj?rn Ekl?v Cc: members-discuss at ripe.net Betreff: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Torbjorn, Equipment which is old enough not to support IPv6+ will probably won't be able to be upgraded to IPv4+ , but it is still using an IPv4 address, and it is the main point, it is using IPv4 address and there is a global need for IPv4 addresses. Regarding homerouters and iot that you wrote - they will not need to be upgraded to IPv4+ , IPv4+ will be transparent to them. Hosts will be upgraded using the automatic update mechanism of their operating system. Respectfully, Elad ________________________________ From: Torbj?rn Ekl?v > Sent: Saturday, April 25, 2020 10:36 PM To: Elad Cohen > Cc: Stuart Willet (primary) >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, More IPv4 will not make the transition faster. If you and other have equipment that can?t be upgraded and support IPv6 its probably to old for IPv4 upgrade also and with all security issues they can?t be patched for. The OS upgrade for some mix with IPv4+ is a bigger issue than IPv6 deployment. There are billions of hosts/homerouters/IoT that never will get an upgrade to support that. /T > On 25 Apr 2020, at 21:13, Elad Cohen > wrote: > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net> > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss > Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at quux.de Sat Apr 25 22:34:57 2020 From: lists at quux.de (Jens Link) Date: Sat, 25 Apr 2020 22:34:57 +0200 Subject: [members-discuss] Another solution to the IPv4 shortage Message-ID: <87o8rfe232.fsf@quux.de> Hi, as I'm struggling to find the political correct words for people subscribing a ticket system to a mailing list with "-discuss" in the name i came up with another solution to the IPv4 shortage: Every person / organization adding this mailing list to a ticket system and thereby creation unnecessary (auto reply) messages or other messages of that kind: - are immediately unsubscribed form any mailing list - forfeit all their resources (IPv4, IPv6, ASN) - can never become a RIPE member again As I just got a mail from a large advertising / could / search engine company this might free up significant resources. Jens -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | ---------------------------------------------------------------------------- From campbell at inca.ie Sat Apr 25 22:45:03 2020 From: campbell at inca.ie (Ed Campbell) Date: Sat, 25 Apr 2020 21:45:03 +0100 Subject: [members-discuss] Another solution to the IPv4 shortage In-Reply-To: <87o8rfe232.fsf@quux.de> References: <87o8rfe232.fsf@quux.de> Message-ID: <8819B4A7-9A2A-4D08-82BF-D48724737195@inca.ie> Yes, I support this. It should be mandatory that lists cannot be subscribed to by groups or ticketing systems. Sent from my iPhone > On 25 Apr 2020, at 21:36, Jens Link wrote: > > ?Hi, > > as I'm struggling to find the political correct words for people > subscribing a ticket system to a mailing list with "-discuss" in the > name i came up with another solution to the IPv4 shortage: > > Every person / organization adding this mailing list to a ticket system > and thereby creation unnecessary (auto reply) messages or other messages > of that kind: > > - are immediately unsubscribed form any mailing list > - forfeit all their resources (IPv4, IPv6, ASN) > - can never become a RIPE member again > > As I just got a mail from a large advertising / could / search engine > company this might free up significant resources. > > > Jens > -- > ---------------------------------------------------------------------------- > | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | > | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | > ---------------------------------------------------------------------------- > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie From elad at netstyle.io Sat Apr 25 22:37:53 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 20:37:53 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <04aa24ccc25b4f9aa4a34e45381a4d12@safehosts.co.uk> References: , <089e01d61b32$236318a0$6a2949e0$@xervers.pt> , <32db0e46cf874f11bf9b916a647c0566@safehosts.co.uk> , <04aa24ccc25b4f9aa4a34e45381a4d12@safehosts.co.uk> Message-ID: Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Saturday, April 25, 2020 11:04 PM To: Atif Naveed ; Elad Cohen ; noc xervers ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Dear Atif, Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. I?m not sure there is a Tier1 who doesn?t offer IPv6. Most UK ISP?s now provide IPv6 by default to people?s homes. I agree the uptake has been incredibly slow, which is why I don?t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. Why would the uptake be faster for IPv4+? Best, Stuart Willet. From: Atif Naveed [mailto:a.naveed at go.com.sa] Sent: 25 April 2020 20:30 To: Stuart Willet (primary) ; Elad Cohen ; noc xervers ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Dear Stuart, Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own path . Regards Atif Naveed Sr. Specialist IGW/ISP Core Network Operations D:+966-11511-1263 E:a.naveed at go.com.sa www.go.com.sa From: members-discuss > On Behalf Of Stuart Willet (primary) Sent: Saturday, April 25, 2020 10:21 PM To: Elad Cohen >; noc xervers >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. What about all the L3 switches and routers not owned by ISP?s? What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 25 April 2020 20:13 To: Stuart Willet (primary) >; noc xervers >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). Regarding the number of devices: * Any routing device with more than two physical routes * Any BGP router * Any operating system The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6. If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Image removed by sender. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Image removed by sender. Visit our website] [Image removed by sender. Facebook] [Image removed by sender. Twitter] [Image removed by sender. TrustPilot] De: members-discuss > Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 482 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 344 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 344 bytes Desc: image003.jpg URL: From elad at netstyle.io Sat Apr 25 23:04:19 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 21:04:19 +0000 Subject: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , Message-ID: Thilo, The problem is that there is a demand in the world for IPv4 and IPv4 will soon runout in all the RIRs. IPv6, to my opinion, is not deployed because it costs money, manpower, IT department, learning, etc - companies are basing their actions on profitable / not profitable - you will not see companies rushing to IPv6 when they are not have to, when IPv4 works perfectly fine for them, they will not put expenses for something that can only cause them more expenses if there will be any problem with the IPv6 deployment (to my opinion this is what the reasonable company will react) and specially in these times of COVID, reasonable companies will minimize expenses and will try less to change things which are working. NAT is being used for many years, and still the demand for IPv4 is huge (all RIRs soon will not have any available single IPv4), datacenters are not using NAT. The main problem with IPv6 is by-design, creating a completely different ip protocol which is not backward-compatible is very bad, the design of it is very bad and it what brought us to this state (and also the 4 byte limitation in IPv4), but I'm not against the deployment of it, the deployment of IPv6 will be completed and I believe that more IPv4 addresses will help the deployment of IPv6, specially in these times we need more connectivity and IPv4+ brings more connectivity in the very immediate near future (IPv6 will do it in the longer term). I do believe also as you wrote that IPv4 addresses will become more and more expensive (if IPv4+ will not be implemented), regulators intervention in each country for IPv4 rate seems to me a more difficult task than the deployment of IPv6 and IPv4+ together :) Respectfully, Elad ________________________________ From: Thilo Mohri Sent: Saturday, April 25, 2020 11:36 PM To: Elad Cohen Cc: members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, I like your solution - however, where is the problem you are trying to solve? The problem we have with IPv6 is absolutely non-technical, most devices natively support IPv6, for legacy devices we have 4in6 and to deal with IPv4 exhaustion we have NAT at least on the b2c side. The solution to IPv4 exhaustion is there - it is called IPv6, it is just not deployed! The problem is with organizations who don?t have IPv6 on their priority list - and this will change over time when IPv4 will get more expensive and not possible to run anymore. I agree it?s a slow adoption, but the market will settle this over time. The only risk I see here is that the market will be dominated by big players in the future as small players cannot get any footprint into the IPv4 market anymore and not able to reach all their customers with IPv6 -> this must be solved by the different telco regulators in the respective countries. Just my two cents, Thilo - sent from my mobile. On 25. Apr 2020, at 22:31, Elad Cohen wrote: ? Michael, Please see my following answers: 1. No additional header bit is needed, the ip packet is exactly as it is now, the 'reserved bit flag' will just be '1' instead of '0' , the reserved bit is available in the ip header and hence the filter will see the whole ip packet. (any router that do any check regarding the source address or the destination - will need to be upgraded). 2. This is not a new protocol, IPv6 is a new protocol, it is an adjustment to a current protocol and not any device which implemented that protocol (IPv4) will need to be upgraded, providing IPv4 address (of IPv4+) to all the parties involved (when IPv4 addresses are so much needed in these days) and using the automatic updating mechanism of operating systems - can and will make this whole process much much faster. 3. It is an adjustment to a current protocol and not a completely new protocol, clean code updates will resolve it. There is no need to know what is the main protocol (IPv4+ or IPv4) because the exact same IPv4 packet is being used, upgraded routers will just know how to route it well (if the four bytes of source address are of IPv4 or IPv4+ and if the four bytes of destination address are of IPv4 or IPv4+). 4. Please see what I wrote, I didn't write that only some of the needed routers will be upgraded, I wrote that all the end-users operating systems will be updated (through the automatic updating mechanism of the operating systems). 5. We can argue on it, I believe that if companies and organizations will have a high pool of IPv4 then they will be able to support both IPv6 and IPv4 and then more and more companies and organizations will support both IPv4 and IPv6 until the whole internet will be able to move to only IPv6. IPv6 is being talked for 20 years and currently the world is in a very big problem because of the lack of IPv4. 6. From the very beginning with the round table and IPv4+ addresses incentives to everyone - IPv4+ will be deployed very very fast, I wrote about very margins cases, from the very beginning through the round table IPv4+ will be deployed (Automatic operating system updates will done only after the ISP's and ASN's will complete to update their routers and will receive their amount of free new IPv4 addresses). And just in case an ISP will assign to its user an IPv4+ addresses to use the internet then that IPv4+ addresses need to access the whole internet (there are many online services that are not yet supporting IPv6+). I'm not against IPv6 - I surely believe it is the future, but more IPv4 addresses are needed for and until IPv6 to be fully adapted. 7. Please write about any unanswered point. I don't believe that I'm late because 20 years ago there wasn't any need to use the 'reserved bit flag' in the ip header, it was intended for future use, and what would be a better use to the 'reserved bit flag' than to use it for the current IPv4 Exhaustion problem. Respectfully, Elad ________________________________ From: members-discuss on behalf of info at cowmedia.de Sent: Saturday, April 25, 2020 11:00 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, i really appreciate your idea, but there are unfortunately some issues to this. 1. It requires an additonal header bit that is not part of the address itself, how would a filter know about this when there is only the ip address given (the bit it not available to them). 2. The time of developing and rollout a new type of protocol (what this is) takes years (maybe 10-15 years) even this is theoretically just a small change) 3. Configuring dual protocol is already with IPv4+6 sometimes a hard issue. There are issues with what protocol is the main one and how applications are using them 4. It is not enough to update only networking equipment because the application layer decides about the target (for example the browser via DNS), even today so many software is not compatible with IPv6, how would you expect them to include IPv4+? 5. IPv4+ would slow down IPv6 rollout 6. Your thinking about users will complain when sites are not reachable is not correct. ISPs and service owner make sure right now that the service is at least reachable by IPv4 and they are in the process of trying to add IPv6 to them. There is no way of having users not access any service just because a provider or any MITM is not yet ready. Hence IPv4+ will NEVER be solely rollout to any service. 7. Plus many more points that were raised. You are really 20 years too late. I am so sorry. Michael Von: members-discuss Im Auftrag von Elad Cohen Gesendet: Samstag, 25. April 2020 21:42 An: Torbj?rn Ekl?v Cc: members-discuss at ripe.net Betreff: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Torbjorn, Equipment which is old enough not to support IPv6+ will probably won't be able to be upgraded to IPv4+ , but it is still using an IPv4 address, and it is the main point, it is using IPv4 address and there is a global need for IPv4 addresses. Regarding homerouters and iot that you wrote - they will not need to be upgraded to IPv4+ , IPv4+ will be transparent to them. Hosts will be upgraded using the automatic update mechanism of their operating system. Respectfully, Elad ________________________________ From: Torbj?rn Ekl?v > Sent: Saturday, April 25, 2020 10:36 PM To: Elad Cohen > Cc: Stuart Willet (primary) >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, More IPv4 will not make the transition faster. If you and other have equipment that can?t be upgraded and support IPv6 its probably to old for IPv4 upgrade also and with all security issues they can?t be patched for. The OS upgrade for some mix with IPv4+ is a bigger issue than IPv6 deployment. There are billions of hosts/homerouters/IoT that never will get an upgrade to support that. /T > On 25 Apr 2020, at 21:13, Elad Cohen > wrote: > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net> > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss > Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/inbox%40tmo.sh -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at quux.de Sat Apr 25 23:15:27 2020 From: lists at quux.de (Jens Link) Date: Sat, 25 Apr 2020 23:15:27 +0200 Subject: [members-discuss] Another solution to the IPv4 shortage In-Reply-To: <87o8rfe232.fsf@quux.de> (Jens Link's message of "Sat, 25 Apr 2020 22:34:57 +0200") References: <87o8rfe232.fsf@quux.de> Message-ID: <87d07ve07k.fsf@quux.de> Jens Link writes: > - are immediately unsubscribed form any mailing list > - forfeit all their resources (IPv4, IPv6, ASN) > - can never become a RIPE member again and the same is true for people using advanced anti spam stuff on mailing lists. Like "Mailinblack anti-spam". Whatever it is but it's quite annoying. Jens (and yes this mail is also a test if my server is correctly bouncing this garbage) -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | ---------------------------------------------------------------------------- From torbjorn.eklov at interlan.se Sat Apr 25 23:15:28 2020 From: torbjorn.eklov at interlan.se (=?utf-8?B?VG9yYmrDtnJuIEVrbMO2dg==?=) Date: Sat, 25 Apr 2020 21:15:28 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <089e01d61b32$236318a0$6a2949e0$@xervers.pt> <32db0e46cf874f11bf9b916a647c0566@safehosts.co.uk> <04aa24ccc25b4f9aa4a34e45381a4d12@safehosts.co.uk> Message-ID: Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It?s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it?s "new? but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed ; Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Atif, > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I?m not sure there is a Tier1 who doesn?t offer IPv6. > Most UK ISP?s now provide IPv6 by default to people?s homes. > > I agree the uptake has been incredibly slow, which is why I don?t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? > > > Best, > > Stuart Willet. > > From: Atif Naveed [mailto:a.naveed at go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) ; Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Stuart, > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own path . > > Regards > > > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed at go.com.sa > www.go.com.sa > > From: members-discuss On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > What about all the L3 switches and routers not owned by ISP?s? > What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > Best, > Stuart Willet. > > From: Elad Cohen [mailto:elad at netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) ; noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se From aleksi at magnacapax.fi Sat Apr 25 23:25:04 2020 From: aleksi at magnacapax.fi (Aleksi) Date: Sun, 26 Apr 2020 00:25:04 +0300 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: <36b7b7c6-0762-0fb7-769f-0a264429ff89@magnacapax.fi> Hi, ?This is interesting, but it would also possible to add more "extensions" -- only end side nodes needs to be upgraded on software level only, client which sends the data, and the regular IPv4 address receiver. No need for backbone level *hardware* upgrades for this. Extend with 2 additional ie. [0-255].[0-255].[0-255].[0-255].[0-255].[0-255] Would be the new maximum on base software. Example: Server is 11.11.11.1 Client is 11.11.12.1.1.1 Router at 11.11.12.1 Server (11.11.11.1) sends packet with additional header data (there is space for this!) with 2 additional bytes for the extension address. Router at 11.11.12.1 gets this packet, looks inside the header and notices the 2 additional bytes and forwards this to client at LOCAL 11.11.12.1.1.1 (L2 lookup) Intermediate switches between router and client do not need to understand this, only end to end, and the router (which could be software driven so 1st step only a linux kernel module!) BGP or routing does not need changes, as no routes of extended addresses are being announced nor allowed to be announced. Therefore each final /32 can be extended by equivalent of /16 with very minimal work -- initially only software upgrades on each side. For years i've been wondering why no one has proposed this, so simple and elegant with minimal hardware investment. *none* of the bloat on IPv6, just a very simple extension. No performance drawbacks on routing level, only "end points" need to support it. Then again, i would wish also maximum packet size to be increased by order of magnitude(s). Proposal by Elad would require hardware level changes on all routers everywhere before being of any use, so sadly i think it will not get any traction. My proposal is unlikely to get any traction either, as it's not to the benefit of big players (who currently holds vast quantities of unused IPv4 address space). I just keep wondering why no one would come up with such a simple idea. This could be done at higher than L3 even -- but atleast initially would be essentially "L3.5" somewhere between L3 and L4... -Aleksi Magna Capax Finland On 4/25/20 9:20 PM, Elad Cohen wrote: > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 > Exhaustion" problem (without to upgrade each and every router that > exist in the internet), using the below implementation there will be > more 4,294,967,296? IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination > address are being represented each by four bytes, each of these four > bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: > four bytes can also be displayed as [0-65535].[0-65535] (two numbers > and one dot, the two numbers are bigger because in total they also > being represented as four bytes) > > So there can be one set of 4,294,967,296? IPv4 addresses (the one that > we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of > [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to > know if the source address is of the old formatting (IPv4) or of the > new formatting (lets call it IPv4+), for that mark the 'reserved bit' > in the ip header can be used, so in case the source address is of > IPv4+ or in case that the destination address is of IPv4+ (or in case > that both the source and destination addresses are of IPv4+) then the > reserved bit in the ip header will be set to 1 , we then also need to > know exactly if the source address is of IPv4+ or not (meaning of > IPv4) and if the destination address is of IPv4+ or not (meaning of > IPv4) - this can be done by marking the DF flag if the source address > is of IPv4+ (and not marking the DF flag if the source address is of > IPv4) and marking the MF flag if the destination address is of IPv4+ > (and not marking the MF flag if the destination address is of IPv4), > by using the DF and MF bits which are related to fragmentation > (whenever the reserved bit is set to '1') we are losing the ip > fragmentation functionality for any traffic with an IPv4+ address (for > traffic between two IPv4 addresses, the reserved bit is not set to '1' > and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because > no fragmentation will be able to be done with IPv4+ , the current > "Path MTU Discovery" (RFC 1191) is not good for that case because it > is using the DF bit which we are using as well (and in IPv4+ traffic a > DF flag set to 1 is marking that the source address is of IPv4+), and > also ICMP protocol can be blocked by routers in the routing path, the > solution is to send multiple udp requests (with fixed known MTU sizes) > to the destination address (lets call it IPv4+ handshake) - the > destination address may or may not receive them (in case a router in > the routing path have multiple upstreams and wasn't upgraded to an > upper version that supports IPv4+ then it will not recognize the > reserved bit and the DF and MF bits related to it, it will not > recognize the new IPv4+ addresses and even if the reserved bit is set > to '1' and MF flag is set to '1' in the ip packet - it will route to > to the destination address just like it is an IPv4 address and not > IPv4+ address, meaning to a completely different destination address) > - in case the destination address indeed received the IPv4+ packets - > it will send back the udp requests to the source address at the exact > same sizes (with the reserved bit flag set to '1' and with the DF and > MF flags set accordingly) - when the source address will receive them > - the source address will know that the destination address is > supporting IPv4+ , that ip packets with new IPv4+ formatting will > reach the destination and the source address will know what is the > biggest size of the udp request that was received - and it will be the > MTU for that specific connection between the source and the > destination addresses (The IPv4+ handshake will be done again if there > is no response from the destination after the initial udp handshake > was already completed successfully). > > The udp handshake between a source address and a destination address > (that any of them or them both is an IPv4+ address) will use a > specific udp port, an availalbe unassigned port between 0 to 1023, an > operating system networking stack (that was updated for IPv4+ with the > operating system automatic updating system) will know exactly what > this udp port is for - and will react accordingly, the upgraded > operating system networking stack will also check that the destination > address (in the IPv4 or in the IPv4+ format) is set locally in the > operating system, before sending the udp requests back to the source > address (if not then the ip packet will be dropped by the upgraded > operating system networking stack). Any operating system that wasn't > upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was > not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is > also not adding any new fields to ip packets or using new fields, > IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the > ToS / IP-ID / Options in ip header are being used is because we cannot > be 100% sure that the ToS / IP-ID / Options in the ip header will not > be changed or dropped by any rouer in the routing path that wasn't > upgraded to IPv4+ (and we don't want to upgrade any router in the > world because it is an impossible mission) - in the ip header ToS is > being cleared by some routers - IP-ID can be changed by NAT routers - > Options field is dropped by many routers, we can trust that the DF and > MF flags will not be modified in the routing path by routers that > weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs > to be patched/upgraded to support IPv4+ which is an impossible > mission, end-users operating systems need to be upgraded (but it can > be done simply using their automatic updating system), BGP routers > (and any router with multiple physical routing paths) will need to > have its firmware upgraded to support IPv4+, any NAT router that will > want to use an external IPv4+ address will need to have its firmware > upgraded (any NAT router that will use an external IPv4 address will > not need to have its firmware upgraded, only the internet devices in > the LAN of the NAT router will need to have a single operating system > update in order for them to access IPv4+ addresses in the internet), > any home router (not NAT) or home modem will not need to have a > firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round > table of one person from each one of the 5 RIRs and from each one of > the operating systems vendors and from each one of the router > manufacture vendors. Even if IPv4+ will be deployed over time, it will > not cause the internet to break (devices that need to be upgraded to > IPv4+ and didn't yet will work exactly as they are now with IPv4, they > will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to > each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that > will be able to the provided to the LIRs worldwide, if you have any > question please let me know. > > Respectfully, > Elad > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sat Apr 25 23:32:29 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 21:32:29 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <089e01d61b32$236318a0$6a2949e0$@xervers.pt> <32db0e46cf874f11bf9b916a647c0566@safehosts.co.uk> <04aa24ccc25b4f9aa4a34e45381a4d12@safehosts.co.uk> , Message-ID: Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad ________________________________ From: Torbj?rn Ekl?v Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen Cc: Stuart Willet (primary) ; Atif Naveed ; noc xervers ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It?s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it?s "new? but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed ; Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Atif, > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I?m not sure there is a Tier1 who doesn?t offer IPv6. > Most UK ISP?s now provide IPv6 by default to people?s homes. > > I agree the uptake has been incredibly slow, which is why I don?t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? > > > Best, > > Stuart Willet. > > From: Atif Naveed [mailto:a.naveed at go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) ; Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Stuart, > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own path . > > Regards > > > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed at go.com.sa > www.go.com.sa > > From: members-discuss On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > What about all the L3 switches and routers not owned by ISP?s? > What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > Best, > Stuart Willet. > > From: Elad Cohen [mailto:elad at netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) ; noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sat Apr 25 23:57:38 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 21:57:38 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <36b7b7c6-0762-0fb7-769f-0a264429ff89@magnacapax.fi> References: , <36b7b7c6-0762-0fb7-769f-0a264429ff89@magnacapax.fi> Message-ID: Aleksei, Regarding: "Server (11.11.11.1) sends packet with additional header data (there is space for this!)" Where is the space in the header ? there isn't any reliable space in the header to increase the source address number or the destination address number Where in the ip header are the two additional bytes for the source address and the two additional bytes for the destination address ? Regarding: "Router at 11.11.12.1 gets this packet, looks inside the header and notices the 2 additional bytes and forwards this to client at LOCAL 11.11.12.1.1.1 (L2 lookup)" In order for the router to look at the 2 additional bytes, the router will need to have its firmware upgrade, so every LAN router in the world will need to have its firmware upgrade. In case you will explain where are the additional two bytes for the source address and the destination address (there isn't any reliable place, many routers will drop the ip packet due to it unless you will firmware-upgrade all the routers in the world - an impossible task) - then the additional ip addresses are only for current existing LANs (new ASNs will need to have ip addresses from the first /32 which do not exist due to the lack of IPv4, networks will need to be restructured to free the first /32 , but main problem with it is that there is no reliable place for additional two bytes for the source address and additional two bytes for the destination address, that the ip packets will always pass - with the changes that were made to them - in each and every router in the world that wasn't upgraded) Regarding: "Proposal by Elad would require hardware level changes on all routers everywhere before being of any use, so sadly i think it will not get any traction." This is not correct - hardware level changes will not be needed on any router, only a software update (which is a firmware upgrade) and not on every router in the world - only in bgp routers and in any non-bgp routers which have more than two physical routers (NAT routers that will use an external IPv4+ address and not an IPv4 will also need to be upgraded, any router in the routing path which is using filtering based on the source or destination addresses - will also need to have a firmware upgrade), any homerouter or home modem will not need to be updated (these are the vast majority of networking equipment in the world). Respectfully, Elad ________________________________ From: members-discuss on behalf of Aleksi Sent: Sunday, April 26, 2020 12:25 AM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, This is interesting, but it would also possible to add more "extensions" -- only end side nodes needs to be upgraded on software level only, client which sends the data, and the regular IPv4 address receiver. No need for backbone level *hardware* upgrades for this. Extend with 2 additional ie. [0-255].[0-255].[0-255].[0-255].[0-255].[0-255] Would be the new maximum on base software. Example: Server is 11.11.11.1 Client is 11.11.12.1.1.1 Router at 11.11.12.1 Server (11.11.11.1) sends packet with additional header data (there is space for this!) with 2 additional bytes for the extension address. Router at 11.11.12.1 gets this packet, looks inside the header and notices the 2 additional bytes and forwards this to client at LOCAL 11.11.12.1.1.1 (L2 lookup) Intermediate switches between router and client do not need to understand this, only end to end, and the router (which could be software driven so 1st step only a linux kernel module!) BGP or routing does not need changes, as no routes of extended addresses are being announced nor allowed to be announced. Therefore each final /32 can be extended by equivalent of /16 with very minimal work -- initially only software upgrades on each side. For years i've been wondering why no one has proposed this, so simple and elegant with minimal hardware investment. *none* of the bloat on IPv6, just a very simple extension. No performance drawbacks on routing level, only "end points" need to support it. Then again, i would wish also maximum packet size to be increased by order of magnitude(s). Proposal by Elad would require hardware level changes on all routers everywhere before being of any use, so sadly i think it will not get any traction. My proposal is unlikely to get any traction either, as it's not to the benefit of big players (who currently holds vast quantities of unused IPv4 address space). I just keep wondering why no one would come up with such a simple idea. This could be done at higher than L3 even -- but atleast initially would be essentially "L3.5" somewhere between L3 and L4... -Aleksi Magna Capax Finland On 4/25/20 9:20 PM, Elad Cohen wrote: Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296? IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296? IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 00:27:19 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 22:27:19 +0000 Subject: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <40375CEC-5F22-4ADC-980A-7353D21DC14D@inca.ie> References: , <40375CEC-5F22-4ADC-980A-7353D21DC14D@inca.ie> Message-ID: In a round table of operating system vendors such as Microsoft and the five RIRs and routing equipment manufacturers, Microsoft will receive a high number of new IPv4+ addresses, so they will have an incentive to deploy the patch to their networking stack fast (all the round table parties will have incentives to quickly create the patches to their systems). IT resellers will not need to know to do anything besides firmware upgrades to routers and a manual patch update to an operating system (in case the specific end-user operating system is not set for automatic updating) It took us approximately 25 years to reach the exhaustion of IPv4, it will take us more 25 years to reach the exhaustion of IPv4+, it will give a lot of time for proper and smooth transition to IPv6. Respectfully, Elad ________________________________ From: members-discuss on behalf of Ed Campbell Sent: Saturday, April 25, 2020 10:24 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world IPv4 is just over allocated and mismanaged from its inception. Allocating /8?s to DoD etc was just a bad idea. While I like your idea, the problem with it would be to get the likes of Microsoft to develop their stack to recognise it. The learning curve for dumb IT resellers would also be huge. The obvious solution is to force the adoption of IPv6 rather than go through another process that will also end up in exhaustion. It may have taken 20 years or so to exhaust IPv4, but the majority of those years weren?t influenced by 4G and now 5G where the demand is going to be extreme. IPv6 is the clear way. Cheer, Ed Sent from my iPhone On 25 Apr 2020, at 20:01, Elad Cohen wrote: ? I never created an RFC and not familiar with the process, but I wanted to discuss IPv4+ with Ripe members as I'm a Ripe LIR. Respectfully, Elad ________________________________ From: info at cowmedia.de Sent: Saturday, April 25, 2020 9:53 PM To: members-discuss at ripe.net Cc: 'noc xervers'; Elad Cohen Subject: AW: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, anyhow this is not the right list to discuss this. You need to create an RfC ? but as IPv6 already exist there is no real chance of implementing this I would say. Michael Von: members-discuss Im Auftrag von noc xervers Gesendet: Samstag, 25. April 2020 20:49 An: 'Elad Cohen' ; members-discuss at ripe.net Betreff: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Das Bild wurde vom Absender entfernt. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Das Bild wurde vom Absender entfernt. Visit our website] [Das Bild wurde vom Absender entfernt. Facebook] [Das Bild wurde vom Absender entfernt. Twitter] [Das Bild wurde vom Absender entfernt. TrustPilot] De: members-discuss Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From campbell at inca.ie Sun Apr 26 00:28:35 2020 From: campbell at inca.ie (Ed Campbell) Date: Sat, 25 Apr 2020 23:28:35 +0100 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: And again, you tell me one vendor that will spend the millions required to develop a software upgrade for this. Where is the economy in that? The ?new? IP space will have ran out in 5 years due to mismanagement and all that would happen is yet another 5 year delay to the full deployment of IPv6. This is not a solution, even if it were feasible, it is a stop gap. IPv6 is not a new protocol it has been around for years now. It is time to push this more than anything else as it literally solves the problem. Sent from my iPhone > On 25 Apr 2020, at 23:14, Elad Cohen wrote: > > ? > Aleksei, > > Regarding: > "Server (11.11.11.1) sends packet with additional header data (there is space for this!)" > > Where is the space in the header ? there isn't any reliable space in the header to increase the source address number or the destination address number > > Where in the ip header are the two additional bytes for the source address and the two additional bytes for the destination address ? > > Regarding: > "Router at 11.11.12.1 gets this packet, looks inside the header and notices the 2 additional bytes and forwards this to client at LOCAL 11.11.12.1.1.1 (L2 lookup)" > > In order for the router to look at the 2 additional bytes, the router will need to have its firmware upgrade, so every LAN router in the world will need to have its firmware upgrade. > > In case you will explain where are the additional two bytes for the source address and the destination address (there isn't any reliable place, many routers will drop the ip packet due to it unless you will firmware-upgrade all the routers in the world - an impossible task) - then the additional ip addresses are only for current existing LANs (new ASNs will need to have ip addresses from the first /32 which do not exist due to the lack of IPv4, networks will need to be restructured to free the first /32 , but main problem with it is that there is no reliable place for additional two bytes for the source address and additional two bytes for the destination address, that the ip packets will always pass - with the changes that were made to them - in each and every router in the world that wasn't upgraded) > > Regarding: > "Proposal by Elad would require hardware level changes on all routers everywhere before being of any use, so sadly i think it will not get any traction." > > This is not correct - hardware level changes will not be needed on any router, only a software update (which is a firmware upgrade) and not on every router in the world - only in bgp routers and in any non-bgp routers which have more than two physical routers (NAT routers that will use an external IPv4+ address and not an IPv4 will also need to be upgraded, any router in the routing path which is using filtering based on the source or destination addresses - will also need to have a firmware upgrade), any homerouter or home modem will not need to be updated (these are the vast majority of networking equipment in the world). > > Respectfully, > Elad > From: members-discuss on behalf of Aleksi > Sent: Sunday, April 26, 2020 12:25 AM > To: members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hi, > > > > This is interesting, but it would also possible to add more "extensions" -- only end side nodes needs to be upgraded on software level only, client which sends the data, and the regular IPv4 address receiver. No need for backbone level *hardware* upgrades for this. > > Extend with 2 additional ie. [0-255].[0-255].[0-255].[0-255].[0-255].[0-255] > Would be the new maximum on base software. > > Example: > Server is 11.11.11.1 > Client is 11.11.12.1.1.1 > Router at 11.11.12.1 > > Server (11.11.11.1) sends packet with additional header data (there is space for this!) with 2 additional bytes for the extension address. > Router at 11.11.12.1 gets this packet, looks inside the header and notices the 2 additional bytes and forwards this to client at LOCAL 11.11.12.1.1.1 (L2 lookup) > > Intermediate switches between router and client do not need to understand this, only end to end, and the router (which could be software driven so 1st step only a linux kernel module!) > > > BGP or routing does not need changes, as no routes of extended addresses are being announced nor allowed to be announced. Therefore each final /32 can be extended by equivalent of /16 with very minimal work -- initially only software upgrades on each side. > > > > For years i've been wondering why no one has proposed this, so simple and elegant with minimal hardware investment. *none* of the bloat on IPv6, just a very simple extension. No performance drawbacks on routing level, only "end points" need to support it. > > > > Then again, i would wish also maximum packet size to be increased by order of magnitude(s). > > Proposal by Elad would require hardware level changes on all routers everywhere before being of any use, so sadly i think it will not get any traction. > > My proposal is unlikely to get any traction either, as it's not to the benefit of big players (who currently holds vast quantities of unused IPv4 address space). I just keep wondering why no one would come up with such a simple idea. This could be done at higher than L3 even -- but atleast initially would be essentially "L3.5" somewhere between L3 and L4... > > > > -Aleksi > Magna Capax Finland > > > >> On 4/25/20 9:20 PM, Elad Cohen wrote: >> Hello Everyone, >> >> I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296? IPv4 addresses that the world needs so much: >> >> Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] >> >> But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) >> >> So there can be one set of 4,294,967,296? IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) >> >> and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) >> >> We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) >> >> We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). >> >> The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. >> >> IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. >> >> The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. >> >> For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. >> >> The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). >> >> The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. >> >> Respectfully, >> Elad >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From campbell at inca.ie Sun Apr 26 00:33:53 2020 From: campbell at inca.ie (Ed Campbell) Date: Sat, 25 Apr 2020 23:33:53 +0100 Subject: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: <7DEEAE26-8A64-42B7-A71C-24C1C6D11BF3@inca.ie> I would disagree with everything you said there. Microsoft getting a large proportion of IO addressing doesn?t help, it hinders the issue. By that logic Google and Amazon and others would also get a large portion. Resellers would have to learn a new addressing scheme. They don?t understand IPv4 now other wise their networks would be smaller that /16 and their public IP requirements for them and their customers would also be smaller. And IPv4 has been more used in the last 5 than the previous 20, it is nonsense to think that it would take another 25 years to exhaust this. It?ll take more than 25 years to exhaust IPv6. Sent from my iPhone > On 25 Apr 2020, at 23:27, Elad Cohen wrote: > > ? > In a round table of operating system vendors such as Microsoft and the five RIRs and routing equipment manufacturers, Microsoft will receive a high number of new IPv4+ addresses, so they will have an incentive to deploy the patch to their networking stack fast (all the round table parties will have incentives to quickly create the patches to their systems). > > IT resellers will not need to know to do anything besides firmware upgrades to routers and a manual patch update to an operating system (in case the specific end-user operating system is not set for automatic updating) > > It took us approximately 25 years to reach the exhaustion of IPv4, it will take us more 25 years to reach the exhaustion of IPv4+, it will give a lot of time for proper and smooth transition to IPv6. > > Respectfully, > Elad > From: members-discuss on behalf of Ed Campbell > Sent: Saturday, April 25, 2020 10:24 PM > To: members-discuss at ripe.net > Subject: Re: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > IPv4 is just over allocated and mismanaged from its inception. Allocating /8?s to DoD etc was just a bad idea. > > While I like your idea, the problem with it would be to get the likes of Microsoft to develop their stack to recognise it. The learning curve for dumb IT resellers would also be huge. > > The obvious solution is to force the adoption of IPv6 rather than go through another process that will also end up in exhaustion. It may have taken 20 years or so to exhaust IPv4, but the majority of those years weren?t influenced by 4G and now 5G where the demand is going to be extreme. IPv6 is the clear way. > > Cheer, > Ed > > > > > Sent from my iPhone > >>> On 25 Apr 2020, at 20:01, Elad Cohen wrote: >>> >> ? >> I never created an RFC and not familiar with the process, but I wanted to discuss IPv4+ with Ripe members as I'm a Ripe LIR. >> >> Respectfully, >> Elad >> >> >> From: info at cowmedia.de >> Sent: Saturday, April 25, 2020 9:53 PM >> To: members-discuss at ripe.net >> Cc: 'noc xervers'; Elad Cohen >> Subject: AW: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world >> >> Hi, >> >> anyhow this is not the right list to discuss this. You need to create an RfC ? but as IPv6 already exist there is no real chance of implementing this I would say. >> >> Michael >> >> Von: members-discuss Im Auftrag von noc xervers >> Gesendet: Samstag, 25. April 2020 20:49 >> An: 'Elad Cohen' ; members-discuss at ripe.net >> Betreff: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world >> >> That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. >> It's a better and cleaner solution to move to IPv6. >> >> Cheers. >> >> >> NOC xervers | +351 300 404 316 >> P Please consider the environment before printing this email >> >> >> >> >> De: members-discuss Em Nome De Elad Cohen >> Enviada: s?bado, 25 de abril de 2020 20:21 >> Para: members-discuss at ripe.net >> Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world >> >> Hello Everyone, >> >> I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: >> >> Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] >> >> But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) >> >> So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) >> >> and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) >> >> We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) >> >> We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). >> >> The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. >> >> IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. >> >> The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. >> >> For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. >> >> The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). >> >> The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. >> >> Respectfully, >> Elad >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 00:37:27 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 22:37:27 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , Message-ID: The vendor will not need to spend millions for a software upgrade, the implementation is very simple, it is exactly the same protocol (IPv4) just with the reserved bit turned on and then two other bit flags are representing the source address and the destination address differently, from a development point of view it is very easy and fast, each vendor can do it in one week. The economy is that also they can develop it fast (it is not a completely new protocol in terms of code development, just few modifications to existing code) and for it they will receive a high number of IPv4+ addresses. Currently the RIRs are very strict on allocating new IPv4 space (the ones that still have) to LIRs and these policies will continue, they will continue to be very strict, so I don't expect IPv4+ to runout fast, it will take at least more 25 years and it will give the whole world time to transfer to IPv6 smoothly. IPv4+ will not stop IPv6, we as the internet community should not cause damage to any party which is connected to the internet and by enforcing IPv6 because of no IPv4 - I don't believe that we are doing good, the world is in problem and I brought my solution - if the internet community will decide to adopt it or not this is your decision. Respectfully, Elad ________________________________ From: Ed Campbell Sent: Sunday, April 26, 2020 1:28 AM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world And again, you tell me one vendor that will spend the millions required to develop a software upgrade for this. Where is the economy in that? The ?new? IP space will have ran out in 5 years due to mismanagement and all that would happen is yet another 5 year delay to the full deployment of IPv6. This is not a solution, even if it were feasible, it is a stop gap. IPv6 is not a new protocol it has been around for years now. It is time to push this more than anything else as it literally solves the problem. Sent from my iPhone On 25 Apr 2020, at 23:14, Elad Cohen wrote: ? Aleksei, Regarding: "Server (11.11.11.1) sends packet with additional header data (there is space for this!)" Where is the space in the header ? there isn't any reliable space in the header to increase the source address number or the destination address number Where in the ip header are the two additional bytes for the source address and the two additional bytes for the destination address ? Regarding: "Router at 11.11.12.1 gets this packet, looks inside the header and notices the 2 additional bytes and forwards this to client at LOCAL 11.11.12.1.1.1 (L2 lookup)" In order for the router to look at the 2 additional bytes, the router will need to have its firmware upgrade, so every LAN router in the world will need to have its firmware upgrade. In case you will explain where are the additional two bytes for the source address and the destination address (there isn't any reliable place, many routers will drop the ip packet due to it unless you will firmware-upgrade all the routers in the world - an impossible task) - then the additional ip addresses are only for current existing LANs (new ASNs will need to have ip addresses from the first /32 which do not exist due to the lack of IPv4, networks will need to be restructured to free the first /32 , but main problem with it is that there is no reliable place for additional two bytes for the source address and additional two bytes for the destination address, that the ip packets will always pass - with the changes that were made to them - in each and every router in the world that wasn't upgraded) Regarding: "Proposal by Elad would require hardware level changes on all routers everywhere before being of any use, so sadly i think it will not get any traction." This is not correct - hardware level changes will not be needed on any router, only a software update (which is a firmware upgrade) and not on every router in the world - only in bgp routers and in any non-bgp routers which have more than two physical routers (NAT routers that will use an external IPv4+ address and not an IPv4 will also need to be upgraded, any router in the routing path which is using filtering based on the source or destination addresses - will also need to have a firmware upgrade), any homerouter or home modem will not need to be updated (these are the vast majority of networking equipment in the world). Respectfully, Elad ________________________________ From: members-discuss on behalf of Aleksi Sent: Sunday, April 26, 2020 12:25 AM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, This is interesting, but it would also possible to add more "extensions" -- only end side nodes needs to be upgraded on software level only, client which sends the data, and the regular IPv4 address receiver. No need for backbone level *hardware* upgrades for this. Extend with 2 additional ie. [0-255].[0-255].[0-255].[0-255].[0-255].[0-255] Would be the new maximum on base software. Example: Server is 11.11.11.1 Client is 11.11.12.1.1.1 Router at 11.11.12.1 Server (11.11.11.1) sends packet with additional header data (there is space for this!) with 2 additional bytes for the extension address. Router at 11.11.12.1 gets this packet, looks inside the header and notices the 2 additional bytes and forwards this to client at LOCAL 11.11.12.1.1.1 (L2 lookup) Intermediate switches between router and client do not need to understand this, only end to end, and the router (which could be software driven so 1st step only a linux kernel module!) BGP or routing does not need changes, as no routes of extended addresses are being announced nor allowed to be announced. Therefore each final /32 can be extended by equivalent of /16 with very minimal work -- initially only software upgrades on each side. For years i've been wondering why no one has proposed this, so simple and elegant with minimal hardware investment. *none* of the bloat on IPv6, just a very simple extension. No performance drawbacks on routing level, only "end points" need to support it. Then again, i would wish also maximum packet size to be increased by order of magnitude(s). Proposal by Elad would require hardware level changes on all routers everywhere before being of any use, so sadly i think it will not get any traction. My proposal is unlikely to get any traction either, as it's not to the benefit of big players (who currently holds vast quantities of unused IPv4 address space). I just keep wondering why no one would come up with such a simple idea. This could be done at higher than L3 even -- but atleast initially would be essentially "L3.5" somewhere between L3 and L4... -Aleksi Magna Capax Finland On 4/25/20 9:20 PM, Elad Cohen wrote: Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296? IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296? IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From campbell at inca.ie Sun Apr 26 00:39:50 2020 From: campbell at inca.ie (Ed Campbell) Date: Sat, 25 Apr 2020 23:39:50 +0100 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: <4B280D9B-EF81-47F5-B077-8B918E871265@inca.ie> IPv6 isn?t slow because of the lack of trying, it is slow because of Microsoft et al?s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a ?nice to have? ?feature? attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this ?new? IPv4 space, that just doesn?t track with the current demand for addressing. You?d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone > On 25 Apr 2020, at 22:34, Elad Cohen wrote: > > ? > Torbjorn, > > IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. > > Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. > > I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. > > It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. > > CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. > > Respectfully, > Elad > From: Torbj?rn Ekl?v > Sent: Sunday, April 26, 2020 12:15 AM > To: Elad Cohen > Cc: Stuart Willet (primary) ; Atif Naveed ; noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Elad, > > > > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. > > No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It?s more complicated and more time consuming than deploying IPv6. > > > > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) > > Yes, it?s "new? but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. > > /Tobbe > > > > > > Respectfully, > > Elad > > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 11:04 PM > > To: Atif Naveed ; Elad Cohen ; noc xervers ; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > > > Dear Atif, > > > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > > I?m not sure there is a Tier1 who doesn?t offer IPv6. > > Most UK ISP?s now provide IPv6 by default to people?s homes. > > > > I agree the uptake has been incredibly slow, which is why I don?t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > > Why would the uptake be faster for IPv4+? > > > > > > Best, > > > > Stuart Willet. > > > > From: Atif Naveed [mailto:a.naveed at go.com.sa] > > Sent: 25 April 2020 20:30 > > To: Stuart Willet (primary) ; Elad Cohen ; noc xervers ; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > > > Dear Stuart, > > > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > > > And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own path . > > > > Regards > > > > > > Atif Naveed > > Sr. Specialist > > IGW/ISP Core Network Operations > > D:+966-11511-1263 > > E:a.naveed at go.com.sa > > www.go.com.sa > > > > From: members-discuss On Behalf Of Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 10:21 PM > > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > > > What about all the L3 switches and routers not owned by ISP?s? > > What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > > > Best, > > Stuart Willet. > > > > From: Elad Cohen [mailto:elad at netstyle.io] > > Sent: 25 April 2020 20:13 > > To: Stuart Willet (primary) ; noc xervers ; members-discuss at ripe.net > > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > > > Regarding the number of devices: > > ? Any routing device with more than two physical routes > > ? Any BGP router > > ? Any operating system > > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > > > Respectfully, > > Elad > > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 10:01 PM > > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > > > Best, > > Stuart Willet. > > > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > > Sent: 25 April 2020 19:56 > > To: noc xervers ; members-discuss at ripe.net > > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > > > switches are working on layer2, they are not related to ip. > > > > Respectfully, > > Elad > > > > From: noc xervers > > Sent: Saturday, April 25, 2020 9:48 PM > > To: Elad Cohen ; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > > It's a better and cleaner solution to move to IPv6. > > > > Cheers. > > > > > > NOC xervers | +351 300 404 316 > > P Please consider the environment before printing this email > > > > > > > > > > De: members-discuss Em Nome De Elad Cohen > > Enviada: s?bado, 25 de abril de 2020 20:21 > > Para: members-discuss at ripe.net > > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > > > Hello Everyone, > > > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > > > Respectfully, > > Elad > > _______________________________________________ > > members-discuss mailing list > > members-discuss at ripe.net > > https://lists.ripe.net/mailman/listinfo/members-discuss > > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 00:44:12 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 22:44:12 +0000 Subject: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <7DEEAE26-8A64-42B7-A71C-24C1C6D11BF3@inca.ie> References: , <7DEEAE26-8A64-42B7-A71C-24C1C6D11BF3@inca.ie> Message-ID: New addressing schema of [0-65535].[0-65535] shouldn't be too hard to learn (easier than IPv6 hexa numbers) I don't believe that we as the internet community should block additional IPv4 addresses when the world needs it so much. All the big companies (Microsoft, Google, Amazon, etc) are supporting IPv6 too and will support IPv6 too. I don't believe that we need to put pressure and to decide for internet companies and for internet organizations what is the right moment for them to change to IPv6, yes I do believe it should be done and needs to be done - but only they should decide when will the right moment for them. The current state is bad for the world, what will happen is that the rate of IPv4 will just go up and up and less people will be able to afford it as the time will go by. Respectfully, Elad ________________________________ From: Ed Campbell Sent: Sunday, April 26, 2020 1:33 AM To: Elad Cohen Cc: members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world I would disagree with everything you said there. Microsoft getting a large proportion of IO addressing doesn?t help, it hinders the issue. By that logic Google and Amazon and others would also get a large portion. Resellers would have to learn a new addressing scheme. They don?t understand IPv4 now other wise their networks would be smaller that /16 and their public IP requirements for them and their customers would also be smaller. And IPv4 has been more used in the last 5 than the previous 20, it is nonsense to think that it would take another 25 years to exhaust this. It?ll take more than 25 years to exhaust IPv6. Sent from my iPhone On 25 Apr 2020, at 23:27, Elad Cohen wrote: ? In a round table of operating system vendors such as Microsoft and the five RIRs and routing equipment manufacturers, Microsoft will receive a high number of new IPv4+ addresses, so they will have an incentive to deploy the patch to their networking stack fast (all the round table parties will have incentives to quickly create the patches to their systems). IT resellers will not need to know to do anything besides firmware upgrades to routers and a manual patch update to an operating system (in case the specific end-user operating system is not set for automatic updating) It took us approximately 25 years to reach the exhaustion of IPv4, it will take us more 25 years to reach the exhaustion of IPv4+, it will give a lot of time for proper and smooth transition to IPv6. Respectfully, Elad ________________________________ From: members-discuss on behalf of Ed Campbell Sent: Saturday, April 25, 2020 10:24 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world IPv4 is just over allocated and mismanaged from its inception. Allocating /8?s to DoD etc was just a bad idea. While I like your idea, the problem with it would be to get the likes of Microsoft to develop their stack to recognise it. The learning curve for dumb IT resellers would also be huge. The obvious solution is to force the adoption of IPv6 rather than go through another process that will also end up in exhaustion. It may have taken 20 years or so to exhaust IPv4, but the majority of those years weren?t influenced by 4G and now 5G where the demand is going to be extreme. IPv6 is the clear way. Cheer, Ed Sent from my iPhone On 25 Apr 2020, at 20:01, Elad Cohen wrote: ? I never created an RFC and not familiar with the process, but I wanted to discuss IPv4+ with Ripe members as I'm a Ripe LIR. Respectfully, Elad ________________________________ From: info at cowmedia.de Sent: Saturday, April 25, 2020 9:53 PM To: members-discuss at ripe.net Cc: 'noc xervers'; Elad Cohen Subject: AW: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, anyhow this is not the right list to discuss this. You need to create an RfC ? but as IPv6 already exist there is no real chance of implementing this I would say. Michael Von: members-discuss Im Auftrag von noc xervers Gesendet: Samstag, 25. April 2020 20:49 An: 'Elad Cohen' ; members-discuss at ripe.net Betreff: [SPAM] Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Das Bild wurde vom Absender entfernt. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Das Bild wurde vom Absender entfernt. Visit our website] [Das Bild wurde vom Absender entfernt. Facebook] [Das Bild wurde vom Absender entfernt. Twitter] [Das Bild wurde vom Absender entfernt. TrustPilot] De: members-discuss Em Nome De Elad Cohen Enviada: s?bado, 25 de abril de 2020 20:21 Para: members-discuss at ripe.net Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 00:52:40 2020 From: elad at netstyle.io (Elad Cohen) Date: Sat, 25 Apr 2020 22:52:40 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <4B280D9B-EF81-47F5-B077-8B918E871265@inca.ie> References: , <4B280D9B-EF81-47F5-B077-8B918E871265@inca.ie> Message-ID: Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad ________________________________ From: Ed Campbell Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen Cc: Torbj?rn Ekl?v ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world IPv6 isn?t slow because of the lack of trying, it is slow because of Microsoft et al?s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a ?nice to have? ?feature? attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this ?new? IPv4 space, that just doesn?t track with the current demand for addressing. You?d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen wrote: ? Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad ________________________________ From: Torbj?rn Ekl?v Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen Cc: Stuart Willet (primary) ; Atif Naveed ; noc xervers ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It?s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it?s "new? but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed ; Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Atif, > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I?m not sure there is a Tier1 who doesn?t offer IPv6. > Most UK ISP?s now provide IPv6 by default to people?s homes. > > I agree the uptake has been incredibly slow, which is why I don?t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? > > > Best, > > Stuart Willet. > > From: Atif Naveed [mailto:a.naveed at go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) ; Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Stuart, > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own path . > > Regards > > > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed at go.com.sa > www.go.com.sa > > From: members-discuss On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > What about all the L3 switches and routers not owned by ISP?s? > What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > Best, > Stuart Willet. > > From: Elad Cohen [mailto:elad at netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) ; noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From noc at xervers.pt Sun Apr 26 09:23:27 2020 From: noc at xervers.pt (noc) Date: Sun, 26 Apr 2020 09:23:27 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: Message-ID: Hello Elad.I've been reading all the messages you sent. I see that you try hard to push your vision. But here's some reasons to what you suggest doesn't work and will never work:- the extra 2 bits you suggest to use (fragmentation bits) are there for a reason. And that reason is not to have more ips, but to fragment packets when needed. On a perfect worldwide network, they aren't needed. But we are on a imperfect worldwide network and many systems need packet fragmentation to work (satellite systems by example).- it's not possible to upgrade millions of routers. Many reached end-of-life many years ago. If the ISP switch the router, he will deploy right away ipv6.- IPv4+ will not give more time to deploy IPv6. It will only delay it. Everyone is lazy for different reasons. So, if IPv4 works, why deploy IPv6? No. It's been since 2012 that we (RIPE) announced the exhaustion of IPv4. And very few has been done to push IPv6.- enterprises like Microsoft will earn a lot more of IPv4+ if they implement it... Why will they bother? They already have 2 /8 legacy not being used/routed. And this is the same for a lot other companies. Many already invested a lot on IPv6, will they do new investments for IPv4+ knowing that is a dead end? No.- IPv4+ is easy to implement. Wrong. It's hard. It will need to be implemented on each level till the top (IANA), and I doubt the very top will do anything to change this.?Looking at the statistics everywhere, I see that IPv6 implementation his growing a lot since September. And this, yes. It's a good news.Your idea should've be pushed 15 years ago (before the running out announcement), not now. Now there is nothing it can be done.CheersEnviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original --------De : Elad Cohen Data: 26/04/20 00:54 (GMT+01:00) Para: Ed Campbell Cc: members-discuss at ripe.net Assunto: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad From: Ed Campbell Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen Cc: Torbj?rn Ekl?v ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ? IPv6 isn?t slow because of the lack of trying, it is slow because of Microsoft et al?s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a ?nice to have? ?feature? attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this ?new? IPv4 space, that just doesn?t track with the current demand for addressing. You?d only be delaying and thwarting existing efforts to deploy IPv6.? Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen wrote: ? Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad From: Torbj?rn Ekl?v Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen Cc: Stuart Willet (primary) ; Atif Naveed ; noc xervers ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ? Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now.? It?s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it?s "new? but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing.? IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed ; Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world >? > Dear Atif, >? > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I?m not sure there is a Tier1 who doesn?t offer IPv6. > Most UK ISP?s now provide IPv6 by default to people?s homes. >? > I agree the uptake has been incredibly slow, which is why I don?t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? >? >? > Best, >? > Stuart Willet. >? > From: Atif Naveed [mailto:a.naveed at go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) ; Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world >? > Dear Stuart, >? > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. >? > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. >? > And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own? path . >? > Regards >? >? > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed at go.com.sa > www.go.com.sa >? > From: members-discuss On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world >? > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. >? > What about all the L3 switches and routers not owned by ISP?s? > What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? >? > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. >? > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. >? > Best, > Stuart Willet. >? > From: Elad Cohen [mailto:elad at netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) ; noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world >? > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). >? > Regarding the number of devices: >??????? ? Any routing device with more than two physical routes >??????? ? Any BGP router >??????? ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). >? > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). >? > Respectfully, > Elad > From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world >? > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. >? > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. >? > Best, > Stuart Willet. >? > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world >? > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. >? > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. >? > switches are working on layer2, they are not related to ip. >? > Respectfully, > Elad >? > From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world >? > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. >? > Cheers. >? > > NOC xervers | +351 300 404 316 > P?? Please consider the environment before printing this email > ? > >? >? > De: members-discuss Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world >? > Hello Everyone, >? > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: >? > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] >? > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) >? > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) >? > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) >? > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) >? > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). >? > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. >? > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. >? > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. >? > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. >? > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). >? > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. >? > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From tl at hartl-edv.de Sun Apr 26 09:43:44 2020 From: tl at hartl-edv.de (Tobias Lehner) Date: Sun, 26 Apr 2020 07:43:44 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: <3c31eee4e5c34e99b026f0fa9fbb1d1b@Hartl30.hartl-edv.de> Hi, Furthermore, every router in the connection can/may add/remove the df bit, which breaks your idea. We should really go in the direction of IPv6. Mit freundlichen Gr??en / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: members-discuss Im Auftrag von noc Gesendet: Sonntag, 26. April 2020 09:23 An: Elad Cohen ; Ed Campbell Cc: members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Elad. I've been reading all the messages you sent. I see that you try hard to push your vision. But here's some reasons to what you suggest doesn't work and will never work: - the extra 2 bits you suggest to use (fragmentation bits) are there for a reason. And that reason is not to have more ips, but to fragment packets when needed. On a perfect worldwide network, they aren't needed. But we are on a imperfect worldwide network and many systems need packet fragmentation to work (satellite systems by example). - it's not possible to upgrade millions of routers. Many reached end-of-life many years ago. If the ISP switch the router, he will deploy right away ipv6. - IPv4+ will not give more time to deploy IPv6. It will only delay it. Everyone is lazy for different reasons. So, if IPv4 works, why deploy IPv6? No. It's been since 2012 that we (RIPE) announced the exhaustion of IPv4. And very few has been done to push IPv6. - enterprises like Microsoft will earn a lot more of IPv4+ if they implement it... Why will they bother? They already have 2 /8 legacy not being used/routed. And this is the same for a lot other companies. Many already invested a lot on IPv6, will they do new investments for IPv4+ knowing that is a dead end? No. - IPv4+ is easy to implement. Wrong. It's hard. It will need to be implemented on each level till the top (IANA), and I doubt the very top will do anything to change this. Looking at the statistics everywhere, I see that IPv6 implementation his growing a lot since September. And this, yes. It's a good news. Your idea should've be pushed 15 years ago (before the running out announcement), not now. Now there is nothing it can be done. Cheers Enviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original -------- De : Elad Cohen > Data: 26/04/20 00:54 (GMT+01:00) Para: Ed Campbell > Cc: members-discuss at ripe.net Assunto: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad _____ From: Ed Campbell > Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen > Cc: Torbj?rn Ekl?v >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world IPv6 isn?t slow because of the lack of trying, it is slow because of Microsoft et al?s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a ?nice to have? ?feature? attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this ?new? IPv4 space, that just doesn?t track with the current demand for addressing. You?d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen > wrote: ? Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad _____ From: Torbj?rn Ekl?v > Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen > Cc: Stuart Willet (primary) >; Atif Naveed >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It?s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it?s "new? but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed >; Elad Cohen >; noc xervers >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Atif, > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I?m not sure there is a Tier1 who doesn?t offer IPv6. > Most UK ISP?s now provide IPv6 by default to people?s homes. > > I agree the uptake has been incredibly slow, which is why I don?t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? > > > Best, > > Stuart Willet. > > From: Atif Naveed [mailto:a.naveed at go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) >; Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Stuart, > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own path . > > Regards > > > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed at go.com.sa > www.go.com.sa > > From: members-discuss > On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > What about all the L3 switches and routers not owned by ISP?s? > What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > Best, > Stuart Willet. > > From: Elad Cohen [mailto:elad at netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss > Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5407 bytes Desc: not available URL: From elad at netstyle.io Sun Apr 26 09:44:21 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 07:44:21 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , Message-ID: Hello, I'm not trying hard to push my vision, I'm just trying to answer all the people which are obviously part of the IPv6 community and seems to aggressively not have a meantime solution for many years until IPv6 will be fully deployed. There are many people with interests for IPv6, IPv6 brings money to many people in this field, so I'm not surprise to see such kind of response. I'm just answering, the pushers are the ones trying to destroy IPv4 in the path to IPv6, no matter the damages that it will do to enormous number of entities worldwide if the transition to IPv6 will not be smooth. The extra 2 bits (fragmentation bits) are optional by design, fragmentation is not mandatory for each IP packet, it is optional and it is there because there wasn't a fixed MTU, but if we can know what is the MTU for each connection - then the two fragmentation flags are not needed and can be used for another purpose. With the reserved bit that was reserved just for such case - for a case of disaster, for a case that the world needs more IPv4 addresses and that single reserved bit can double the number of IPv4 addresses. Millions of routers will not need to be upgraded for IPv4+ , only bgp routers and only non-bgp routers with more than two physical routes (and any router with ACL's based on the source or destination address), these are not millions of routers, and these are routers managed by IT professionals and not by home users, the upgrading of the needed routers can be fast by the IT professionals. --- Here is an optional adjustment to the idea: Only end-users and servers operating systems will be updated (using the operating systems automatic updating mechanism), using the same way that I wrote with the exact same feasible IPv4 packet modification implementation (reserved bit, no fragmentation, fragmentation flags, udp handshake), no other equipment will need to be updated, no routers will need to be updated at all - but then the routing of IPv4+ addresses will always be to the same destination device that have the same four bytes of destination IPv4 address (meaning routing will be as it is now - based on IPv4 and not on IPv4+). In this way, the number of IPv4 addresses will be doubled and each ASN will double his number of IPv4 addresses, each ASN will have his exact same ip addresses but in two formats - in IPv4 format and in IPv4+ format. (if the community is lazy and don't want to upgrade the needed routers by IT professionals, and it is not the whole routers in the world, far far far less) Respectfully, Elad ________________________________ From: noc Sent: Sunday, April 26, 2020 10:23 AM To: Elad Cohen ; Ed Campbell Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Elad. I've been reading all the messages you sent. I see that you try hard to push your vision. But here's some reasons to what you suggest doesn't work and will never work: - the extra 2 bits you suggest to use (fragmentation bits) are there for a reason. And that reason is not to have more ips, but to fragment packets when needed. On a perfect worldwide network, they aren't needed. But we are on a imperfect worldwide network and many systems need packet fragmentation to work (satellite systems by example). - it's not possible to upgrade millions of routers. Many reached end-of-life many years ago. If the ISP switch the router, he will deploy right away ipv6. - IPv4+ will not give more time to deploy IPv6. It will only delay it. Everyone is lazy for different reasons. So, if IPv4 works, why deploy IPv6? No. It's been since 2012 that we (RIPE) announced the exhaustion of IPv4. And very few has been done to push IPv6. - enterprises like Microsoft will earn a lot more of IPv4+ if they implement it... Why will they bother? They already have 2 /8 legacy not being used/routed. And this is the same for a lot other companies. Many already invested a lot on IPv6, will they do new investments for IPv4+ knowing that is a dead end? No. - IPv4+ is easy to implement. Wrong. It's hard. It will need to be implemented on each level till the top (IANA), and I doubt the very top will do anything to change this. Looking at the statistics everywhere, I see that IPv6 implementation his growing a lot since September. And this, yes. It's a good news. Your idea should've be pushed 15 years ago (before the running out announcement), not now. Now there is nothing it can be done. Cheers Enviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original -------- De : Elad Cohen Data: 26/04/20 00:54 (GMT+01:00) Para: Ed Campbell Cc: members-discuss at ripe.net Assunto: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad ________________________________ From: Ed Campbell Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen Cc: Torbj?rn Ekl?v ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world IPv6 isn?t slow because of the lack of trying, it is slow because of Microsoft et al?s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a ?nice to have? ?feature? attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this ?new? IPv4 space, that just doesn?t track with the current demand for addressing. You?d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen wrote: ? Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad ________________________________ From: Torbj?rn Ekl?v Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen Cc: Stuart Willet (primary) ; Atif Naveed ; noc xervers ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It?s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it?s "new? but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed ; Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Atif, > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I?m not sure there is a Tier1 who doesn?t offer IPv6. > Most UK ISP?s now provide IPv6 by default to people?s homes. > > I agree the uptake has been incredibly slow, which is why I don?t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? > > > Best, > > Stuart Willet. > > From: Atif Naveed [mailto:a.naveed at go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) ; Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Stuart, > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own path . > > Regards > > > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed at go.com.sa > www.go.com.sa > > From: members-discuss On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > What about all the L3 switches and routers not owned by ISP?s? > What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > Best, > Stuart Willet. > > From: Elad Cohen [mailto:elad at netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) ; noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen ; noc xervers ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers ; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen ; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 09:54:25 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 07:54:25 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Message-ID: You didn't fully read my initial post, the MTU with IPv4+ will not be a fixed MTU of 1500 or of any other fixed value, it will be set in the beginning of the connection through a process called: "IPv4+ UDP Handshake" Respectfully, Elad ________________________________ From: Tobias Lehner Sent: Sunday, April 26, 2020 10:51 AM To: Elad Cohen; 'noc'; Ed Campbell Cc: members-discuss at ripe.net Subject: AW: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You cannot be sure to have MTU of 1500 everywhere? Normally routers should not do anything with df bit, but it is possible to flip the df bit on the router. It is required for some cases. Mit freundlichen Gr??en / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: Elad Cohen Gesendet: Sonntag, 26. April 2020 09:48 An: Tobias Lehner ; 'noc' ; Ed Campbell Cc: members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Tobias, Routers will not do anything with the DF and MF flags as long that MTU is fine (and MTU is initially checked with "IPv4+ UDP Handshake") I wrote in previous reply an adjustment to the idea that is quicker to deploy and will not require the routers, but it will lack the RIRs being able to allocate and to assign IPv4+ addresses to LIRs. Each LIR will automatically receive an additional IPv4 address for each current IPv4 address that it have: -------- Here is an optional adjustment to the idea: Only end-users and servers operating systems will be updated (using the operating systems automatic updating mechanism), using the same way that I wrote with the exact same feasible IPv4 packet modification implementation (reserved bit, no fragmentation, fragmentation flags, udp handshake), no other equipment will need to be updated, no routers will need to be updated at all - but then the routing of IPv4+ addresses will always be to the same destination device that have the same four bytes of destination IPv4 address (meaning routing will be as it is now - based on IPv4 and not on IPv4+). In this way, the number of IPv4 addresses will be doubled and each ASN will double his number of IPv4 addresses, each ASN will have his exact same ip addresses but in two formats - in IPv4 format and in IPv4+ format. (if the community is lazy and don't want to upgrade the needed routers by IT professionals, and it is not the whole routers in the world, far far far less) -------- Respectfully, Elad ________________________________ From: Tobias Lehner Sent: Sunday, April 26, 2020 10:43 AM To: 'noc'; Elad Cohen; Ed Campbell Cc: members-discuss at ripe.net Subject: AW: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, Furthermore, every router in the connection can/may add/remove the df bit, which breaks your idea. We should really go in the direction of IPv6. Mit freundlichen Gr??en / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: members-discuss > Im Auftrag von noc Gesendet: Sonntag, 26. April 2020 09:23 An: Elad Cohen >; Ed Campbell > Cc: members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Elad. I've been reading all the messages you sent. I see that you try hard to push your vision. But here's some reasons to what you suggest doesn't work and will never work: - the extra 2 bits you suggest to use (fragmentation bits) are there for a reason. And that reason is not to have more ips, but to fragment packets when needed. On a perfect worldwide network, they aren't needed. But we are on a imperfect worldwide network and many systems need packet fragmentation to work (satellite systems by example). - it's not possible to upgrade millions of routers. Many reached end-of-life many years ago. If the ISP switch the router, he will deploy right away ipv6. - IPv4+ will not give more time to deploy IPv6. It will only delay it. Everyone is lazy for different reasons. So, if IPv4 works, why deploy IPv6? No. It's been since 2012 that we (RIPE) announced the exhaustion of IPv4. And very few has been done to push IPv6. - enterprises like Microsoft will earn a lot more of IPv4+ if they implement it... Why will they bother? They already have 2 /8 legacy not being used/routed. And this is the same for a lot other companies. Many already invested a lot on IPv6, will they do new investments for IPv4+ knowing that is a dead end? No. - IPv4+ is easy to implement. Wrong. It's hard. It will need to be implemented on each level till the top (IANA), and I doubt the very top will do anything to change this. Looking at the statistics everywhere, I see that IPv6 implementation his growing a lot since September. And this, yes. It's a good news. Your idea should've be pushed 15 years ago (before the running out announcement), not now. Now there is nothing it can be done. Cheers Enviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original -------- De : Elad Cohen > Data: 26/04/20 00:54 (GMT+01:00) Para: Ed Campbell > Cc: members-discuss at ripe.net Assunto: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad ________________________________ From: Ed Campbell > Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen > Cc: Torbj?rn Ekl?v >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world IPv6 isn?t slow because of the lack of trying, it is slow because of Microsoft et al?s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a ?nice to have? ?feature? attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this ?new? IPv4 space, that just doesn?t track with the current demand for addressing. You?d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen > wrote: ? Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad ________________________________ From: Torbj?rn Ekl?v > Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen > Cc: Stuart Willet (primary) >; Atif Naveed >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It?s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it?s "new? but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed >; Elad Cohen >; noc xervers >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Atif, > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I?m not sure there is a Tier1 who doesn?t offer IPv6. > Most UK ISP?s now provide IPv6 by default to people?s homes. > > I agree the uptake has been incredibly slow, which is why I don?t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? > > > Best, > > Stuart Willet. > > From: Atif Naveed [mailto:a.naveed at go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) >; Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Stuart, > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own path . > > Regards > > > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed at go.com.sa > www.go.com.sa > > From: members-discuss > On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > What about all the L3 switches and routers not owned by ISP?s? > What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > Best, > Stuart Willet. > > From: Elad Cohen [mailto:elad at netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net> > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss > Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From tl at hartl-edv.de Sun Apr 26 10:01:35 2020 From: tl at hartl-edv.de (Tobias Lehner) Date: Sun, 26 Apr 2020 08:01:35 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: <95f0bb4838be4734b4459c2703913edd@Hartl30.hartl-edv.de> Then you need to update software of all routers. Any router in the path must not switch the df bit. Every piece of network hardware must be verified or updated, which would cause a big delay in implementing. If it is not checked some router may flip the df bit and you would not get a connectoin. I guess to setup IPv6 is more straightforward and would not cause this delay. Because we have it already. It is a nice idea of you but it will fail at the implementing or causes several delay. Mit freundlichen Gr??en / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: Elad Cohen Gesendet: Sonntag, 26. April 2020 09:54 An: Tobias Lehner ; 'noc' ; Ed Campbell Cc: members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You didn't fully read my initial post, the MTU with IPv4+ will not be a fixed MTU of 1500 or of any other fixed value, it will be set in the beginning of the connection through a process called: "IPv4+ UDP Handshake" Respectfully, Elad _____ From: Tobias Lehner Sent: Sunday, April 26, 2020 10:51 AM To: Elad Cohen; 'noc'; Ed Campbell Cc: members-discuss at ripe.net Subject: AW: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You cannot be sure to have MTU of 1500 everywhere? Normally routers should not do anything with df bit, but it is possible to flip the df bit on the router. It is required for some cases. Mit freundlichen Gr??en / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: Elad Cohen > Gesendet: Sonntag, 26. April 2020 09:48 An: Tobias Lehner >; 'noc' >; Ed Campbell > Cc: members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Tobias, Routers will not do anything with the DF and MF flags as long that MTU is fine (and MTU is initially checked with "IPv4+ UDP Handshake") I wrote in previous reply an adjustment to the idea that is quicker to deploy and will not require the routers, but it will lack the RIRs being able to allocate and to assign IPv4+ addresses to LIRs. Each LIR will automatically receive an additional IPv4 address for each current IPv4 address that it have: -------- Here is an optional adjustment to the idea: Only end-users and servers operating systems will be updated (using the operating systems automatic updating mechanism), using the same way that I wrote with the exact same feasible IPv4 packet modification implementation (reserved bit, no fragmentation, fragmentation flags, udp handshake), no other equipment will need to be updated, no routers will need to be updated at all - but then the routing of IPv4+ addresses will always be to the same destination device that have the same four bytes of destination IPv4 address (meaning routing will be as it is now - based on IPv4 and not on IPv4+). In this way, the number of IPv4 addresses will be doubled and each ASN will double his number of IPv4 addresses, each ASN will have his exact same ip addresses but in two formats - in IPv4 format and in IPv4+ format. (if the community is lazy and don't want to upgrade the needed routers by IT professionals, and it is not the whole routers in the world, far far far less) -------- Respectfully, Elad _____ From: Tobias Lehner Sent: Sunday, April 26, 2020 10:43 AM To: 'noc'; Elad Cohen; Ed Campbell Cc: members-discuss at ripe.net Subject: AW: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, Furthermore, every router in the connection can/may add/remove the df bit, which breaks your idea. We should really go in the direction of IPv6. Mit freundlichen Gr??en / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: members-discuss > Im Auftrag von noc Gesendet: Sonntag, 26. April 2020 09:23 An: Elad Cohen >; Ed Campbell > Cc: members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Elad. I've been reading all the messages you sent. I see that you try hard to push your vision. But here's some reasons to what you suggest doesn't work and will never work: - the extra 2 bits you suggest to use (fragmentation bits) are there for a reason. And that reason is not to have more ips, but to fragment packets when needed. On a perfect worldwide network, they aren't needed. But we are on a imperfect worldwide network and many systems need packet fragmentation to work (satellite systems by example). - it's not possible to upgrade millions of routers. Many reached end-of-life many years ago. If the ISP switch the router, he will deploy right away ipv6. - IPv4+ will not give more time to deploy IPv6. It will only delay it. Everyone is lazy for different reasons. So, if IPv4 works, why deploy IPv6? No. It's been since 2012 that we (RIPE) announced the exhaustion of IPv4. And very few has been done to push IPv6. - enterprises like Microsoft will earn a lot more of IPv4+ if they implement it... Why will they bother? They already have 2 /8 legacy not being used/routed. And this is the same for a lot other companies. Many already invested a lot on IPv6, will they do new investments for IPv4+ knowing that is a dead end? No. - IPv4+ is easy to implement. Wrong. It's hard. It will need to be implemented on each level till the top (IANA), and I doubt the very top will do anything to change this. Looking at the statistics everywhere, I see that IPv6 implementation his growing a lot since September. And this, yes. It's a good news. Your idea should've be pushed 15 years ago (before the running out announcement), not now. Now there is nothing it can be done. Cheers Enviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original -------- De : Elad Cohen > Data: 26/04/20 00:54 (GMT+01:00) Para: Ed Campbell > Cc: members-discuss at ripe.net Assunto: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad _____ From: Ed Campbell > Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen > Cc: Torbj?rn Ekl?v >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world IPv6 isn?t slow because of the lack of trying, it is slow because of Microsoft et al?s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a ?nice to have? ?feature? attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this ?new? IPv4 space, that just doesn?t track with the current demand for addressing. You?d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen > wrote: ? Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad _____ From: Torbj?rn Ekl?v > Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen > Cc: Stuart Willet (primary) >; Atif Naveed >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It?s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it?s "new? but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed >; Elad Cohen >; noc xervers >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Atif, > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I?m not sure there is a Tier1 who doesn?t offer IPv6. > Most UK ISP?s now provide IPv6 by default to people?s homes. > > I agree the uptake has been incredibly slow, which is why I don?t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? > > > Best, > > Stuart Willet. > > From: Atif Naveed [mailto:a.naveed at go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) >; Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Stuart, > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own path . > > Regards > > > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed at go.com.sa > www.go.com.sa > > From: members-discuss > On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > What about all the L3 switches and routers not owned by ISP?s? > What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > Best, > Stuart Willet. > > From: Elad Cohen [mailto:elad at netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss > Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5407 bytes Desc: not available URL: From elad at netstyle.io Sun Apr 26 09:47:57 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 07:47:57 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Message-ID: Tobias, Routers will not do anything with the DF and MF flags as long that MTU is fine (and MTU is initially checked with "IPv4+ UDP Handshake") I wrote in previous reply an adjustment to the idea that is quicker to deploy and will not require the routers, but it will lack the RIRs being able to allocate and to assign IPv4+ addresses to LIRs. Each LIR will automatically receive an additional IPv4 address for each current IPv4 address that it have: -------- Here is an optional adjustment to the idea: Only end-users and servers operating systems will be updated (using the operating systems automatic updating mechanism), using the same way that I wrote with the exact same feasible IPv4 packet modification implementation (reserved bit, no fragmentation, fragmentation flags, udp handshake), no other equipment will need to be updated, no routers will need to be updated at all - but then the routing of IPv4+ addresses will always be to the same destination device that have the same four bytes of destination IPv4 address (meaning routing will be as it is now - based on IPv4 and not on IPv4+). In this way, the number of IPv4 addresses will be doubled and each ASN will double his number of IPv4 addresses, each ASN will have his exact same ip addresses but in two formats - in IPv4 format and in IPv4+ format. (if the community is lazy and don't want to upgrade the needed routers by IT professionals, and it is not the whole routers in the world, far far far less) -------- Respectfully, Elad ________________________________ From: Tobias Lehner Sent: Sunday, April 26, 2020 10:43 AM To: 'noc'; Elad Cohen; Ed Campbell Cc: members-discuss at ripe.net Subject: AW: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, Furthermore, every router in the connection can/may add/remove the df bit, which breaks your idea. We should really go in the direction of IPv6. Mit freundlichen Gr??en / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: members-discuss Im Auftrag von noc Gesendet: Sonntag, 26. April 2020 09:23 An: Elad Cohen ; Ed Campbell Cc: members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Elad. I've been reading all the messages you sent. I see that you try hard to push your vision. But here's some reasons to what you suggest doesn't work and will never work: - the extra 2 bits you suggest to use (fragmentation bits) are there for a reason. And that reason is not to have more ips, but to fragment packets when needed. On a perfect worldwide network, they aren't needed. But we are on a imperfect worldwide network and many systems need packet fragmentation to work (satellite systems by example). - it's not possible to upgrade millions of routers. Many reached end-of-life many years ago. If the ISP switch the router, he will deploy right away ipv6. - IPv4+ will not give more time to deploy IPv6. It will only delay it. Everyone is lazy for different reasons. So, if IPv4 works, why deploy IPv6? No. It's been since 2012 that we (RIPE) announced the exhaustion of IPv4. And very few has been done to push IPv6. - enterprises like Microsoft will earn a lot more of IPv4+ if they implement it... Why will they bother? They already have 2 /8 legacy not being used/routed. And this is the same for a lot other companies. Many already invested a lot on IPv6, will they do new investments for IPv4+ knowing that is a dead end? No. - IPv4+ is easy to implement. Wrong. It's hard. It will need to be implemented on each level till the top (IANA), and I doubt the very top will do anything to change this. Looking at the statistics everywhere, I see that IPv6 implementation his growing a lot since September. And this, yes. It's a good news. Your idea should've be pushed 15 years ago (before the running out announcement), not now. Now there is nothing it can be done. Cheers Enviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original -------- De : Elad Cohen > Data: 26/04/20 00:54 (GMT+01:00) Para: Ed Campbell > Cc: members-discuss at ripe.net Assunto: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad ________________________________ From: Ed Campbell > Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen > Cc: Torbj?rn Ekl?v >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world IPv6 isn?t slow because of the lack of trying, it is slow because of Microsoft et al?s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a ?nice to have? ?feature? attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this ?new? IPv4 space, that just doesn?t track with the current demand for addressing. You?d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen > wrote: ? Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad ________________________________ From: Torbj?rn Ekl?v > Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen > Cc: Stuart Willet (primary) >; Atif Naveed >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It?s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it?s "new? but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed >; Elad Cohen >; noc xervers >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Atif, > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I?m not sure there is a Tier1 who doesn?t offer IPv6. > Most UK ISP?s now provide IPv6 by default to people?s homes. > > I agree the uptake has been incredibly slow, which is why I don?t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? > > > Best, > > Stuart Willet. > > From: Atif Naveed [mailto:a.naveed at go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) >; Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Stuart, > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own path . > > Regards > > > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed at go.com.sa > www.go.com.sa > > From: members-discuss > On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > What about all the L3 switches and routers not owned by ISP?s? > What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > Best, > Stuart Willet. > > From: Elad Cohen [mailto:elad at netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net> > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss > Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From tl at hartl-edv.de Sun Apr 26 09:51:29 2020 From: tl at hartl-edv.de (Tobias Lehner) Date: Sun, 26 Apr 2020 07:51:29 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: <6d2ce7a25bd14ce2bd15100b1d053cb5@Hartl30.hartl-edv.de> You cannot be sure to have MTU of 1500 everywhere? Normally routers should not do anything with df bit, but it is possible to flip the df bit on the router. It is required for some cases. Mit freundlichen Gr??en / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: Elad Cohen Gesendet: Sonntag, 26. April 2020 09:48 An: Tobias Lehner ; 'noc' ; Ed Campbell Cc: members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Tobias, Routers will not do anything with the DF and MF flags as long that MTU is fine (and MTU is initially checked with "IPv4+ UDP Handshake") I wrote in previous reply an adjustment to the idea that is quicker to deploy and will not require the routers, but it will lack the RIRs being able to allocate and to assign IPv4+ addresses to LIRs. Each LIR will automatically receive an additional IPv4 address for each current IPv4 address that it have: -------- Here is an optional adjustment to the idea: Only end-users and servers operating systems will be updated (using the operating systems automatic updating mechanism), using the same way that I wrote with the exact same feasible IPv4 packet modification implementation (reserved bit, no fragmentation, fragmentation flags, udp handshake), no other equipment will need to be updated, no routers will need to be updated at all - but then the routing of IPv4+ addresses will always be to the same destination device that have the same four bytes of destination IPv4 address (meaning routing will be as it is now - based on IPv4 and not on IPv4+). In this way, the number of IPv4 addresses will be doubled and each ASN will double his number of IPv4 addresses, each ASN will have his exact same ip addresses but in two formats - in IPv4 format and in IPv4+ format. (if the community is lazy and don't want to upgrade the needed routers by IT professionals, and it is not the whole routers in the world, far far far less) -------- Respectfully, Elad _____ From: Tobias Lehner Sent: Sunday, April 26, 2020 10:43 AM To: 'noc'; Elad Cohen; Ed Campbell Cc: members-discuss at ripe.net Subject: AW: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, Furthermore, every router in the connection can/may add/remove the df bit, which breaks your idea. We should really go in the direction of IPv6. Mit freundlichen Gr??en / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: members-discuss > Im Auftrag von noc Gesendet: Sonntag, 26. April 2020 09:23 An: Elad Cohen >; Ed Campbell > Cc: members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Elad. I've been reading all the messages you sent. I see that you try hard to push your vision. But here's some reasons to what you suggest doesn't work and will never work: - the extra 2 bits you suggest to use (fragmentation bits) are there for a reason. And that reason is not to have more ips, but to fragment packets when needed. On a perfect worldwide network, they aren't needed. But we are on a imperfect worldwide network and many systems need packet fragmentation to work (satellite systems by example). - it's not possible to upgrade millions of routers. Many reached end-of-life many years ago. If the ISP switch the router, he will deploy right away ipv6. - IPv4+ will not give more time to deploy IPv6. It will only delay it. Everyone is lazy for different reasons. So, if IPv4 works, why deploy IPv6? No. It's been since 2012 that we (RIPE) announced the exhaustion of IPv4. And very few has been done to push IPv6. - enterprises like Microsoft will earn a lot more of IPv4+ if they implement it... Why will they bother? They already have 2 /8 legacy not being used/routed. And this is the same for a lot other companies. Many already invested a lot on IPv6, will they do new investments for IPv4+ knowing that is a dead end? No. - IPv4+ is easy to implement. Wrong. It's hard. It will need to be implemented on each level till the top (IANA), and I doubt the very top will do anything to change this. Looking at the statistics everywhere, I see that IPv6 implementation his growing a lot since September. And this, yes. It's a good news. Your idea should've be pushed 15 years ago (before the running out announcement), not now. Now there is nothing it can be done. Cheers Enviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original -------- De : Elad Cohen > Data: 26/04/20 00:54 (GMT+01:00) Para: Ed Campbell > Cc: members-discuss at ripe.net Assunto: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad _____ From: Ed Campbell > Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen > Cc: Torbj?rn Ekl?v >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world IPv6 isn?t slow because of the lack of trying, it is slow because of Microsoft et al?s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a ?nice to have? ?feature? attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this ?new? IPv4 space, that just doesn?t track with the current demand for addressing. You?d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen > wrote: ? Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad _____ From: Torbj?rn Ekl?v > Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen > Cc: Stuart Willet (primary) >; Atif Naveed >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It?s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it?s "new? but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed >; Elad Cohen >; noc xervers >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Atif, > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I?m not sure there is a Tier1 who doesn?t offer IPv6. > Most UK ISP?s now provide IPv6 by default to people?s homes. > > I agree the uptake has been incredibly slow, which is why I don?t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? > > > Best, > > Stuart Willet. > > From: Atif Naveed [mailto:a.naveed at go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) >; Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Stuart, > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own path . > > Regards > > > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed at go.com.sa > www.go.com.sa > > From: members-discuss > On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > What about all the L3 switches and routers not owned by ISP?s? > What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > Best, > Stuart Willet. > > From: Elad Cohen [mailto:elad at netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss > Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5407 bytes Desc: not available URL: From ck at cksoft.de Sun Apr 26 10:12:51 2020 From: ck at cksoft.de (Christian Kratzer) Date: Sun, 26 Apr 2020 10:12:51 +0200 (CEST) Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: Hi, On Sun, 26 Apr 2020, Elad Cohen wrote: > You didn't fully read my initial post, the MTU with IPv4+ will not be a fixed MTU of 1500 or of any other fixed value, it will be set in the beginning of the connection through a process called: "IPv4+ UDP Handshake" > > Respectfully, > Elad Respectfully your solution does not solve any problem. It just creates new ones. There is no connectivity between IPv4 and IPv4+. So clients needing access to both world need to "dual stack" or even "triple stack" if they also need IPv6. To enable connectivity between IPv4 and IPv4+ you would need routers to support 33 bit routes which is not going to happen. To enable a client to connect to both the IPv4 and IPv4+ internet it seems to me that you would need at least another address family in the socket protocols which is also a massive overhead. The formatting of the address as two 16 bit values instead of four 8 bit values does not fix the issue in the clients ipv4 stack. You cannot route ipv4 and ipv4+ in the same global internet if they are two seprate networks and if the addresses mean different things depending on arbitrary address bits. So I fail to see how in any way your solution would provide more adresses to the existing internet without creating a new isolated cloud. IPv6 can coexist with IPv4 because it has been designed appropriately as a fully separate protocol with clean separation in the the ip stack via a separate address family. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck at cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From elad at netstyle.io Sun Apr 26 10:13:03 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 08:13:03 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Message-ID: Did you see any implementation of a router that on its own flip the DF bit? According to all of my checks it doesn't happen - the fragmentation bits are reliable - meaning not modified by routers in the routing path. No every router in world will need to be updated, in a case that a router will flip the DF bit (there is no online record of such case to happen that routers change on their own fragmentation bits, in the whole internet) then the IPv4+ packet will not reach the destination in the initial "IPv4+ UDP Handshake" and hence the communication (after a successfull "IPv4+ UDP Handshake") will not happen. Respectfully, Elad ________________________________ From: Tobias Lehner Sent: Sunday, April 26, 2020 11:01 AM To: Elad Cohen; 'noc'; Ed Campbell Cc: members-discuss at ripe.net Subject: AW: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Then you need to update software of all routers. Any router in the path must not switch the df bit. Every piece of network hardware must be verified or updated, which would cause a big delay in implementing. If it is not checked some router may flip the df bit and you would not get a connectoin. I guess to setup IPv6 is more straightforward and would not cause this delay. Because we have it already. It is a nice idea of you but it will fail at the implementing or causes several delay. Mit freundlichen Gr??en / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: Elad Cohen Gesendet: Sonntag, 26. April 2020 09:54 An: Tobias Lehner ; 'noc' ; Ed Campbell Cc: members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You didn't fully read my initial post, the MTU with IPv4+ will not be a fixed MTU of 1500 or of any other fixed value, it will be set in the beginning of the connection through a process called: "IPv4+ UDP Handshake" Respectfully, Elad ________________________________ From: Tobias Lehner Sent: Sunday, April 26, 2020 10:51 AM To: Elad Cohen; 'noc'; Ed Campbell Cc: members-discuss at ripe.net Subject: AW: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You cannot be sure to have MTU of 1500 everywhere? Normally routers should not do anything with df bit, but it is possible to flip the df bit on the router. It is required for some cases. Mit freundlichen Gr??en / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: Elad Cohen > Gesendet: Sonntag, 26. April 2020 09:48 An: Tobias Lehner >; 'noc' >; Ed Campbell > Cc: members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Tobias, Routers will not do anything with the DF and MF flags as long that MTU is fine (and MTU is initially checked with "IPv4+ UDP Handshake") I wrote in previous reply an adjustment to the idea that is quicker to deploy and will not require the routers, but it will lack the RIRs being able to allocate and to assign IPv4+ addresses to LIRs. Each LIR will automatically receive an additional IPv4 address for each current IPv4 address that it have: -------- Here is an optional adjustment to the idea: Only end-users and servers operating systems will be updated (using the operating systems automatic updating mechanism), using the same way that I wrote with the exact same feasible IPv4 packet modification implementation (reserved bit, no fragmentation, fragmentation flags, udp handshake), no other equipment will need to be updated, no routers will need to be updated at all - but then the routing of IPv4+ addresses will always be to the same destination device that have the same four bytes of destination IPv4 address (meaning routing will be as it is now - based on IPv4 and not on IPv4+). In this way, the number of IPv4 addresses will be doubled and each ASN will double his number of IPv4 addresses, each ASN will have his exact same ip addresses but in two formats - in IPv4 format and in IPv4+ format. (if the community is lazy and don't want to upgrade the needed routers by IT professionals, and it is not the whole routers in the world, far far far less) -------- Respectfully, Elad ________________________________ From: Tobias Lehner Sent: Sunday, April 26, 2020 10:43 AM To: 'noc'; Elad Cohen; Ed Campbell Cc: members-discuss at ripe.net Subject: AW: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, Furthermore, every router in the connection can/may add/remove the df bit, which breaks your idea. We should really go in the direction of IPv6. Mit freundlichen Gr??en / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: members-discuss > Im Auftrag von noc Gesendet: Sonntag, 26. April 2020 09:23 An: Elad Cohen >; Ed Campbell > Cc: members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Elad. I've been reading all the messages you sent. I see that you try hard to push your vision. But here's some reasons to what you suggest doesn't work and will never work: - the extra 2 bits you suggest to use (fragmentation bits) are there for a reason. And that reason is not to have more ips, but to fragment packets when needed. On a perfect worldwide network, they aren't needed. But we are on a imperfect worldwide network and many systems need packet fragmentation to work (satellite systems by example). - it's not possible to upgrade millions of routers. Many reached end-of-life many years ago. If the ISP switch the router, he will deploy right away ipv6. - IPv4+ will not give more time to deploy IPv6. It will only delay it. Everyone is lazy for different reasons. So, if IPv4 works, why deploy IPv6? No. It's been since 2012 that we (RIPE) announced the exhaustion of IPv4. And very few has been done to push IPv6. - enterprises like Microsoft will earn a lot more of IPv4+ if they implement it... Why will they bother? They already have 2 /8 legacy not being used/routed. And this is the same for a lot other companies. Many already invested a lot on IPv6, will they do new investments for IPv4+ knowing that is a dead end? No. - IPv4+ is easy to implement. Wrong. It's hard. It will need to be implemented on each level till the top (IANA), and I doubt the very top will do anything to change this. Looking at the statistics everywhere, I see that IPv6 implementation his growing a lot since September. And this, yes. It's a good news. Your idea should've be pushed 15 years ago (before the running out announcement), not now. Now there is nothing it can be done. Cheers Enviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original -------- De : Elad Cohen > Data: 26/04/20 00:54 (GMT+01:00) Para: Ed Campbell > Cc: members-discuss at ripe.net Assunto: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad ________________________________ From: Ed Campbell > Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen > Cc: Torbj?rn Ekl?v >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world IPv6 isn?t slow because of the lack of trying, it is slow because of Microsoft et al?s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a ?nice to have? ?feature? attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this ?new? IPv4 space, that just doesn?t track with the current demand for addressing. You?d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen > wrote: ? Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad ________________________________ From: Torbj?rn Ekl?v > Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen > Cc: Stuart Willet (primary) >; Atif Naveed >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It?s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it?s "new? but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed >; Elad Cohen >; noc xervers >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Atif, > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I?m not sure there is a Tier1 who doesn?t offer IPv6. > Most UK ISP?s now provide IPv6 by default to people?s homes. > > I agree the uptake has been incredibly slow, which is why I don?t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? > > > Best, > > Stuart Willet. > > From: Atif Naveed [mailto:a.naveed at go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) >; Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Dear Stuart, > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > And I can understand deployment will be not that?s straight forward but once it starts flying it will make its own path . > > Regards > > > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed at go.com.sa > www.go.com.sa > > From: members-discuss > On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > What about all the L3 switches and routers not owned by ISP?s? > What about bigger ISP?s ad Tier 1?s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > Best, > Stuart Willet. > > From: Elad Cohen [mailto:elad at netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) >; noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > ? Any routing device with more than two physical routes > ? Any BGP router > ? Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) > > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen >; noc xervers >; members-discuss at ripe.net> > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers > > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen >; members-discuss at ripe.net > > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > > > > > De: members-discuss > Em Nome De Elad Cohen > Enviada: s?bado, 25 de abril de 2020 20:21 > Para: members-discuss at ripe.net > Assunto: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world > > Hello Everyone, > > I want to share with you my technical solution to the "IPv4 Exhaustion" problem (without to upgrade each and every router that exist in the internet), using the below implementation there will be more 4,294,967,296 IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination address are being represented each by four bytes, each of these four bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: four bytes can also be displayed as [0-65535].[0-65535] (two numbers and one dot, the two numbers are bigger because in total they also being represented as four bytes) > > So there can be one set of 4,294,967,296 IPv4 addresses (the one that we know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know if the source address is of the old formatting (IPv4) or of the new formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip header can be used, so in case the source address is of IPv4+ or in case that the destination address is of IPv4+ (or in case that both the source and destination addresses are of IPv4+) then the reserved bit in the ip header will be set to 1 , we then also need to know exactly if the source address is of IPv4+ or not (meaning of IPv4) and if the destination address is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF flag if the source address is of IPv4+ (and not marking the DF flag if the source address is of IPv4) and marking the MF flag if the destination address is of IPv4+ (and not marking the MF flag if the destination address is of IPv4), by using the DF and MF bits which are related to fragmentation (whenever the reserved bit is set to '1') we are losing the ip fragmentation functionality for any traffic with an IPv4+ address (for traffic between two IPv4 addresses, the reserved bit is not set to '1' and hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no fragmentation will be able to be done with IPv4+ , the current "Path MTU Discovery" (RFC 1191) is not good for that case because it is using the DF bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is marking that the source address is of IPv4+), and also ICMP protocol can be blocked by routers in the routing path, the solution is to send multiple udp requests (with fixed known MTU sizes) to the destination address (lets call it IPv4+ handshake) - the destination address may or may not receive them (in case a router in the routing path have multiple upstreams and wasn't upgraded to an upper version that supports IPv4+ then it will not recognize the reserved bit and the DF and MF bits related to it, it will not recognize the new IPv4+ addresses and even if the reserved bit is set to '1' and MF flag is set to '1' in the ip packet - it will route to to the destination address just like it is an IPv4 address and not IPv4+ address, meaning to a completely different destination address) - in case the destination address indeed received the IPv4+ packets - it will send back the udp requests to the source address at the exact same sizes (with the reserved bit flag set to '1' and with the DF and MF flags set accordingly) - when the source address will receive them - the source address will know that the destination address is supporting IPv4+ , that ip packets with new IPv4+ formatting will reach the destination and the source address will know what is the biggest size of the udp request that was received - and it will be the MTU for that specific connection between the source and the destination addresses (The IPv4+ handshake will be done again if there is no response from the destination after the initial udp handshake was already completed successfully). > > The udp handshake between a source address and a destination address (that any of them or them both is an IPv4+ address) will use a specific udp port, an availalbe unassigned port between 0 to 1023, an operating system networking stack (that was updated for IPv4+ with the operating system automatic updating system) will know exactly what this udp port is for - and will react accordingly, the upgraded operating system networking stack will also check that the destination address (in the IPv4 or in the IPv4+ format) is set locally in the operating system, before sending the udp requests back to the source address (if not then the ip packet will be dropped by the upgraded operating system networking stack). Any operating system that wasn't upgraded to support IPv4+ - will just drop that kind of udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not adding any new fields to ip packets or using new fields, IPv4+ will not cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS / IP-ID / Options in ip header are being used is because we cannot be 100% sure that the ToS / IP-ID / Options in the ip header will not be changed or dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and we don't want to upgrade any router in the world because it is an impossible mission) - in the ip header ToS is being cleared by some routers - IP-ID can be changed by NAT routers - Options field is dropped by many routers, we can trust that the DF and MF flags will not be modified in the routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to be patched/upgraded to support IPv4+ which is an impossible mission, end-users operating systems need to be upgraded (but it can be done simply using their automatic updating system), BGP routers (and any router with multiple physical routing paths) will need to have its firmware upgraded to support IPv4+, any NAT router that will want to use an external IPv4+ address will need to have its firmware upgraded (any NAT router that will use an external IPv4 address will not need to have its firmware upgraded, only the internet devices in the LAN of the NAT router will need to have a single operating system update in order for them to access IPv4+ addresses in the internet), any home router (not NAT) or home modem will not need to have a firmware upgrade and IPv4+ functionality will be transparent to them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of one person from each one of the 5 RIRs and from each one of the operating systems vendors and from each one of the router manufacture vendors. Even if IPv4+ will be deployed over time, it will not cause the internet to break (devices that need to be upgraded to IPv4+ and didn't yet will work exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be able to the provided to the LIRs worldwide, if you have any question please let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From ck at cksoft.de Sun Apr 26 10:31:53 2020 From: ck at cksoft.de (Christian Kratzer) Date: Sun, 26 Apr 2020 10:31:53 +0200 (CEST) Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , Message-ID: Hi Elad, On Sun, 26 Apr 2020, Elad Cohen wrote: > Christian, > > I'm sorry to write, but you didn't understand how IPv4+ works. And everything that you wrote regarding IPv4+ is completely incorrect. Everything about IPv4+ is completely inpractical. > "There is no connectivity between IPv4 and IPv4+" - IPv4+ is IPv4, exact same protocol. > > "you would need routers to support 33 bit routes which is not going to happen" - This is completely incorrect, route bits are exactly the same. The ip address is the clients identity. That is how it is routed. Routing cannot route ipv4 and ipv4+ packets to different destinations because packets are routed by the destination address only. So while the core networks would transpart packets between LIR the LIR themselves would not be able to route packets to different clients. > "To enable a client to connect to both the IPv4 and IPv4+ internet it seems to me that you would need at least another address family in the socket protocols which is also a massive overhead. The formatting of the address as two 16 bit values instead of four 8 bit values does not fix the issue in the clients ipv4 stack." - No another address family is needed, the source address and destination are exactly in the four bytes each as they are now - the only difference is the application layer in the operating system - based if the single reserved bit flag is on or off - the ip address will be displayed with one dot (IPv4+) or with three dots (IPv4). The string represenation of the address is not the criteria how existing socket api work. The api work internally with 32 bit values. There is no formatting in them. > "You cannot route ipv4 and ipv4+ in the same global internet if they are two seprate networks and if the addresses mean different things depending on arbitrary address bits." - It is the same network, IPv4 (I'm calling it IPv4+ to represent the one-dot addressing to higher application layers, but it is the same IPv4 packets, same IPv4 network) You can only have more addresses if you add bits to the addresses. > I'm not against IPv6, IPv6 and IPv4 will always co-exist in some way, IPv4+ brings more ip addresses to IPv4, it doesn't disturb a bit IPv6. it breaks ipv4. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck at cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From elad at netstyle.io Sun Apr 26 10:24:27 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 08:24:27 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , Message-ID: Christian, I'm sorry to write, but you didn't understand how IPv4+ works. And everything that you wrote regarding IPv4+ is completely incorrect. "There is no connectivity between IPv4 and IPv4+" - IPv4+ is IPv4, exact same protocol. "you would need routers to support 33 bit routes which is not going to happen" - This is completely incorrect, route bits are exactly the same. "To enable a client to connect to both the IPv4 and IPv4+ internet it seems to me that you would need at least another address family in the socket protocols which is also a massive overhead. The formatting of the address as two 16 bit values instead of four 8 bit values does not fix the issue in the clients ipv4 stack." - No another address family is needed, the source address and destination are exactly in the four bytes each as they are now - the only difference is the application layer in the operating system - based if the single reserved bit flag is on or off - the ip address will be displayed with one dot (IPv4+) or with three dots (IPv4). "You cannot route ipv4 and ipv4+ in the same global internet if they are two seprate networks and if the addresses mean different things depending on arbitrary address bits." - It is the same network, IPv4 (I'm calling it IPv4+ to represent the one-dot addressing to higher application layers, but it is the same IPv4 packets, same IPv4 network) I'm not against IPv6, IPv6 and IPv4 will always co-exist in some way, IPv4+ brings more ip addresses to IPv4, it doesn't disturb a bit IPv6. Respectfully, Elad ________________________________ From: Christian Kratzer Sent: Sunday, April 26, 2020 11:12 AM To: Elad Cohen Cc: Tobias Lehner ; 'noc' ; Ed Campbell ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, On Sun, 26 Apr 2020, Elad Cohen wrote: > You didn't fully read my initial post, the MTU with IPv4+ will not be a fixed MTU of 1500 or of any other fixed value, it will be set in the beginning of the connection through a process called: "IPv4+ UDP Handshake" > > Respectfully, > Elad Respectfully your solution does not solve any problem. It just creates new ones. There is no connectivity between IPv4 and IPv4+. So clients needing access to both world need to "dual stack" or even "triple stack" if they also need IPv6. To enable connectivity between IPv4 and IPv4+ you would need routers to support 33 bit routes which is not going to happen. To enable a client to connect to both the IPv4 and IPv4+ internet it seems to me that you would need at least another address family in the socket protocols which is also a massive overhead. The formatting of the address as two 16 bit values instead of four 8 bit values does not fix the issue in the clients ipv4 stack. You cannot route ipv4 and ipv4+ in the same global internet if they are two seprate networks and if the addresses mean different things depending on arbitrary address bits. So I fail to see how in any way your solution would provide more adresses to the existing internet without creating a new isolated cloud. IPv6 can coexist with IPv4 because it has been designed appropriately as a fully separate protocol with clean separation in the the ip stack via a separate address family. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck at cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 10:47:18 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 08:47:18 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , , Message-ID: Christian, Let me explain: "The ip address is the clients identity. That is how it is routed. Routing cannot route ipv4 and ipv4+ packets to different destinations because packets are routed by the destination address only." - Routers do not route ip packets based on the 32 bits of the destination address in binary format, they route based on the representation of [0-255].[0-255].[0-255].[0-255] - four decimal numbers in specific ranges between 0 to 255 separated by dots, each decimal number is one byte, in total 4 bytes like they are in the source address or destination address field in the ip header. If the reserved bit flag in the ip header is set to '1' (the reserved bit is not a new bit to be added to the ip header, it is already exist and it is currently set to '0' , we will set it to '1' ) - then the exact same four bytes of the source address (just for the example) will be represented as [0-65535].[0-65535] , meaning two decimal numbers with bigger ranges separated by one dot (the ranges are bigger because each of these two decimal numbers if of two bytes - in total four bytes just like [0-255].[0-255].[0-255].[0-255] ) - by setting the reserved bit to '1' or to '0' we can tell the router if the four bytes - meaning the 32 bits of the source address (just for the example) are in the format of [0-255].[0-255].[0-255].[0-255] if reserved bit is '0' or in the format of [0-65535].[0-65535] if reserved bit '1' , based on it the router will know what is the ip address and then will route it accordingly (routers that have no more than two physical routes - will not need to check the reserved bit in order to know what is the format, they will just forward the ip packet to the other physical route). Regarding: "The string represenation of the address is not the criteria how existing socket api work. The api work internally with 32 bit values. There is no formatting in them." - It is related to the implementation of the operating system internally in the operating system, single patch to the operating system through the automatic update mechanism of the operating system - will resolve it (As part of global IPv4+ implementation there will be a single remote update to each operating system that will want to support IPv4+). Regarding: "You can only have more addresses if you add bits to the addresses." - Please see my first explanation above on how the same four bytes can be used in ip packets with different representation by using the currently unused reserved bit flag in the ip packet. Respectfully, Elad ________________________________ From: Christian Kratzer Sent: Sunday, April 26, 2020 11:31 AM To: Elad Cohen Cc: Tobias Lehner ; 'noc' ; Ed Campbell ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi Elad, On Sun, 26 Apr 2020, Elad Cohen wrote: > Christian, > > I'm sorry to write, but you didn't understand how IPv4+ works. And everything that you wrote regarding IPv4+ is completely incorrect. Everything about IPv4+ is completely inpractical. > "There is no connectivity between IPv4 and IPv4+" - IPv4+ is IPv4, exact same protocol. > > "you would need routers to support 33 bit routes which is not going to happen" - This is completely incorrect, route bits are exactly the same. The ip address is the clients identity. That is how it is routed. Routing cannot route ipv4 and ipv4+ packets to different destinations because packets are routed by the destination address only. So while the core networks would transpart packets between LIR the LIR themselves would not be able to route packets to different clients. > "To enable a client to connect to both the IPv4 and IPv4+ internet it seems to me that you would need at least another address family in the socket protocols which is also a massive overhead. The formatting of the address as two 16 bit values instead of four 8 bit values does not fix the issue in the clients ipv4 stack." - No another address family is needed, the source address and destination are exactly in the four bytes each as they are now - the only difference is the application layer in the operating system - based if the single reserved bit flag is on or off - the ip address will be displayed with one dot (IPv4+) or with three dots (IPv4). The string represenation of the address is not the criteria how existing socket api work. The api work internally with 32 bit values. There is no formatting in them. > "You cannot route ipv4 and ipv4+ in the same global internet if they are two seprate networks and if the addresses mean different things depending on arbitrary address bits." - It is the same network, IPv4 (I'm calling it IPv4+ to represent the one-dot addressing to higher application layers, but it is the same IPv4 packets, same IPv4 network) You can only have more addresses if you add bits to the addresses. > I'm not against IPv6, IPv6 and IPv4 will always co-exist in some way, IPv4+ brings more ip addresses to IPv4, it doesn't disturb a bit IPv6. it breaks ipv4. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck at cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From br1 at br1.com Sun Apr 26 10:51:13 2020 From: br1 at br1.com (Bruno Cordioli) Date: Sun, 26 Apr 2020 10:51:13 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: Hi All, I think it is appropriate to close this discussion here. Elad will eventually submit his proposed al RIPE meeting or he'll write a RFC. In the meantime we can reread these one from 1994 and one from 1998 :) https://tools.ietf.org/html/rfc1726 https://tools.ietf.org/html/rfc2460 have nice sunday br1 On Sun, Apr 26, 2020 at 10:32 AM Christian Kratzer wrote: > Hi Elad, > > On Sun, 26 Apr 2020, Elad Cohen wrote: > > Christian, > > > > I'm sorry to write, but you didn't understand how IPv4+ works. And > everything that you wrote regarding IPv4+ is completely incorrect. > > Everything about IPv4+ is completely inpractical. > > > "There is no connectivity between IPv4 and IPv4+" - IPv4+ is IPv4, exact > same protocol. > > > > "you would need routers to support 33 bit routes which is not going to > happen" - This is completely incorrect, route bits are exactly the same. > > The ip address is the clients identity. That is how it is routed. Routing > cannot route ipv4 and ipv4+ packets to different destinations because > packets are routed by the destination address only. > > So while the core networks would transpart packets between LIR the LIR > themselves would not be able to route packets to different clients. > > > "To enable a client to connect to both the IPv4 and IPv4+ internet it > seems to me that you would need at least another address family in the > socket protocols which is also a massive overhead. The formatting of the > address as two 16 bit values instead of four 8 bit values does not fix the > issue in the clients ipv4 stack." - No another address family is needed, > the source address and destination are exactly in the four bytes each as > they are now - the only difference is the application layer in the > operating system - based if the single reserved bit flag is on or off - the > ip address will be displayed with one dot (IPv4+) or with three dots (IPv4). > > The string represenation of the address is not the criteria how existing > socket api work. The api work internally with 32 bit values. There is no > formatting in them. > > > "You cannot route ipv4 and ipv4+ in the same global internet if they are > two seprate networks and if the addresses mean different things depending > on arbitrary address bits." - It is the same network, IPv4 (I'm calling it > IPv4+ to represent the one-dot addressing to higher application layers, but > it is the same IPv4 packets, same IPv4 network) > > You can only have more addresses if you add bits to the addresses. > > > I'm not against IPv6, IPv6 and IPv4 will always co-exist in some way, > IPv4+ brings more ip addresses to IPv4, it doesn't disturb a bit IPv6. > > it breaks ipv4. > > Greetings > Christian > > -- > Christian Kratzer CK Software GmbH > Email: ck at cksoft.de Wildberger Weg 24/2 > Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden > Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart > Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer > Web: http://www.cksoft.de/ > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/br1%40br1.com > -- Bruno 'br1' Cordioli www.br1.com br1 at br1.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Sun Apr 26 11:09:30 2020 From: gert at space.net (Gert Doering) Date: Sun, 26 Apr 2020 11:09:30 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: <20200426090930.GN50230@Space.Net> Hi, On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: > I think it is appropriate to close this discussion here. > Elad will eventually submit his proposed al RIPE meeting or he'll write a > RFC. Basically, this. The Internet (and the address distribution towards IANA and the RIRs) operates based on IETF standards, and as long as there is no IETF standard for IPv4+, it cannot be implemented in an interoperable way, and can not be deployed. Elad, this is your avenue: you need to demonstrate two working and interoperating implementations for two host stacks and two router stacks. Just claming "it is easy" is not sufficient. I'm with Christian here: this can not work without significant changes to the BSD socket API, to applications using this API - basically, everything on Unix/Linux - to the Windows networking API, and to routers in the ISP networks that need to decide "which customer is this packet sent to?" based on the extra bit. And I speak with a certain background on implementing network applications, running an ISP network, and debugging TCP/IP stacks. Overall, as long as no implementations can be provided (source code on github etc) this sounds like a somewhat cheap shot to make people believe you're going to solve their IPv4 problems if they just vote you to the NCC executive board. And I hope the NCC members are smart enough to not vote based on glorious promises, but on track record, provable background, etc. Gert Doering -- RIPE member -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From sander at steffann.nl Sun Apr 26 11:28:07 2020 From: sander at steffann.nl (Sander Steffann) Date: Sun, 26 Apr 2020 11:28:07 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <20200426090930.GN50230@Space.Net> References: <20200426090930.GN50230@Space.Net> Message-ID: Hi, > On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: >> I think it is appropriate to close this discussion here. >> Elad will eventually submit his proposed al RIPE meeting or he'll write a >> RFC. > > Basically, this. Seconded > [...] > > Overall, as long as no implementations can be provided (source code on > github etc) this sounds like a somewhat cheap shot to make people believe > you're going to solve their IPv4 problems if they just vote you to the > NCC executive board. And I hope the NCC members are smart enough to not > vote based on glorious promises, but on track record, provable background, > etc. I have contacted Elad off-list and shown him many fallacies in his design. He insisted implementation and deployment of IPv4+ was easy. I told him he is delusional and that I emailed him off-list as not to shame him publicly, and all he said was: > Go ahead, shame me publicly and you will receive the exact same answers, you are obviously have interests regarding IPv6 and you are trying to avoid from the world more IPv4 addresses just for your own personal profit. > > You are obviously have illegal interests in Ripe and this is the only reasons for your emails to me. There is no talking sense into this person. He is oblivious to how the internet works and how hardware and software upgrades are implemented and deployed. Obviously pointing out his flaws means I have an illegal interest somehow. I think Elad has already tried following Trump's recent advice and we are seeing the consequences? Time to move on? Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From elad at netstyle.io Sun Apr 26 11:34:05 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 09:34:05 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Message-ID: Gert, It is completely repulsive what you are doing here, me sharing an idea and the implementation of it and you wrote what you wrote. To the community: Anyone that knows me know that everything I write can be implemented, Gert didn't say that it cannot be implemented - just that modifying the networking stacks is hard - if it it is hard then better developers are needed that it will be easy for them - I'm not going to waste my time on implementing the patches to the networking stacks for Microsoft/Google/Apple/etc - they have their own engineers. I have enough experience in development to know that the reserved bit activation and ipv4 packet modification in the networking stack will not be time consuming such as creating a complete new protocol family, any operating system vendor have enough engineers that can together do it quickly. If after reading everything that I wrote you are calling it a cheap shot then you are not a professional and your background mean nothing (professional people will be able to read algorithems and methods and to know if they works or not, with implementing them in their heads, without to see it in their eyes the electrical signals flowing between machines). Keep on Gert to defame me after I explained this idea and implementation to the community, the difference between us is that I have the decency to know that I know nothing and I always strive to learn, you will not see me pat my ego like you just did, if you don't have something useful to say then go back to your two-threads working group. I didn't promise anything, as long there are hateful people like - nothing good will happen. Respectfully, Elad ________________________________ From: Gert Doering Sent: Sunday, April 26, 2020 12:09 PM To: Bruno Cordioli Cc: Elad Cohen; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: > I think it is appropriate to close this discussion here. > Elad will eventually submit his proposed al RIPE meeting or he'll write a > RFC. Basically, this. The Internet (and the address distribution towards IANA and the RIRs) operates based on IETF standards, and as long as there is no IETF standard for IPv4+, it cannot be implemented in an interoperable way, and can not be deployed. Elad, this is your avenue: you need to demonstrate two working and interoperating implementations for two host stacks and two router stacks. Just claming "it is easy" is not sufficient. I'm with Christian here: this can not work without significant changes to the BSD socket API, to applications using this API - basically, everything on Unix/Linux - to the Windows networking API, and to routers in the ISP networks that need to decide "which customer is this packet sent to?" based on the extra bit. And I speak with a certain background on implementing network applications, running an ISP network, and debugging TCP/IP stacks. Overall, as long as no implementations can be provided (source code on github etc) this sounds like a somewhat cheap shot to make people believe you're going to solve their IPv4 problems if they just vote you to the NCC executive board. And I hope the NCC members are smart enough to not vote based on glorious promises, but on track record, provable background, etc. Gert Doering -- RIPE member -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 11:37:06 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 09:37:06 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426090930.GN50230@Space.Net>, Message-ID: Hello Everyone, What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? First there was the IPv6 fans and now there are the Spamhaus fans. Respectfully, Elad ________________________________ From: members-discuss on behalf of Sander Steffann Sent: Sunday, April 26, 2020 12:28 PM To: Gert D?ring Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: >> I think it is appropriate to close this discussion here. >> Elad will eventually submit his proposed al RIPE meeting or he'll write a >> RFC. > > Basically, this. Seconded > [...] > > Overall, as long as no implementations can be provided (source code on > github etc) this sounds like a somewhat cheap shot to make people believe > you're going to solve their IPv4 problems if they just vote you to the > NCC executive board. And I hope the NCC members are smart enough to not > vote based on glorious promises, but on track record, provable background, > etc. I have contacted Elad off-list and shown him many fallacies in his design. He insisted implementation and deployment of IPv4+ was easy. I told him he is delusional and that I emailed him off-list as not to shame him publicly, and all he said was: > Go ahead, shame me publicly and you will receive the exact same answers, you are obviously have interests regarding IPv6 and you are trying to avoid from the world more IPv4 addresses just for your own personal profit. > > You are obviously have illegal interests in Ripe and this is the only reasons for your emails to me. There is no talking sense into this person. He is oblivious to how the internet works and how hardware and software upgrades are implemented and deployed. Obviously pointing out his flaws means I have an illegal interest somehow. I think Elad has already tried following Trump's recent advice and we are seeing the consequences? Time to move on? Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sun Apr 26 11:40:46 2020 From: sander at steffann.nl (Sander Steffann) Date: Sun, 26 Apr 2020 11:40:46 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426090930.GN50230@Space.Net> Message-ID: <03FC043F-8B18-4C23-95F8-A8D5F13764AA@steffann.nl> Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home? * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From stu at safehosts.co.uk Sun Apr 26 11:46:30 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Sun, 26 Apr 2020 09:46:30 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426090930.GN50230@Space.Net>, Message-ID: Respectfully Elad, you are pushing your idea without considering the consequences. There is no operation against you, we are just trying to point out the flaws in your idea. Just consider this, you are currently speaking with the group that will inevitably be the ones to roll out your idea. If you are having this much trouble convincing us this is a good idea, how would the rest of the world hold up? You keep saying this will work with existing IPv4 but it simply won't will it. I have a home internet connection provided by BT. They give me an IPv4 and an IPv6 address. Traffic preferences IPv6 where it can. How would IPv4+ be added in this scenario? Simple, a firmware update would need to be made on my router. And every router for every other BT customer. Same will apply for VirginMedia et-al. You keep saying it won't be needed unless there is NAT, but most home routers use NAT. Please explain to me how you think Microsoft are going to spend millions on your upgrade for zero benefit to them? Please explain how ISP's will recall and replace millions of set top boxes and modems? Please explain how upgrades are going to be done on end of life switches and routers? Please explain how every DNS server on the planet will be upgraded seamlessly? Seriously, if you are having this hard a time winning us over, you don't stand a chance. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:37 To: Sander Steffann ; Gert D?ring Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? First there was the IPv6 fans and now there are the Spamhaus fans. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Sander Steffann > Sent: Sunday, April 26, 2020 12:28 PM To: Gert D?ring > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: >> I think it is appropriate to close this discussion here. >> Elad will eventually submit his proposed al RIPE meeting or he'll write a >> RFC. > > Basically, this. Seconded > [...] > > Overall, as long as no implementations can be provided (source code on > github etc) this sounds like a somewhat cheap shot to make people believe > you're going to solve their IPv4 problems if they just vote you to the > NCC executive board. And I hope the NCC members are smart enough to not > vote based on glorious promises, but on track record, provable background, > etc. I have contacted Elad off-list and shown him many fallacies in his design. He insisted implementation and deployment of IPv4+ was easy. I told him he is delusional and that I emailed him off-list as not to shame him publicly, and all he said was: > Go ahead, shame me publicly and you will receive the exact same answers, you are obviously have interests regarding IPv6 and you are trying to avoid from the world more IPv4 addresses just for your own personal profit. > > You are obviously have illegal interests in Ripe and this is the only reasons for your emails to me. There is no talking sense into this person. He is oblivious to how the internet works and how hardware and software upgrades are implemented and deployed. Obviously pointing out his flaws means I have an illegal interest somehow. I think Elad has already tried following Trump's recent advice and we are seeing the consequences... Time to move on... Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 11:52:54 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 09:52:54 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Message-ID: Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home? * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Sun Apr 26 11:54:31 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Sun, 26 Apr 2020 09:54:31 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> Elad, You are now making yourself look a little paranoid and silly. Respectfully, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:53 To: Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home... * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 11:58:40 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 09:58:40 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426090930.GN50230@Space.Net>, , Message-ID: Stuart, I don't have any trouble convincing you, the people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Sunday, April 26, 2020 12:46 PM To: Elad Cohen ; Sander Steffann ; Gert D?ring Cc: members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Respectfully Elad, you are pushing your idea without considering the consequences. There is no operation against you, we are just trying to point out the flaws in your idea. Just consider this, you are currently speaking with the group that will inevitably be the ones to roll out your idea. If you are having this much trouble convincing us this is a good idea, how would the rest of the world hold up? You keep saying this will work with existing IPv4 but it simply won?t will it. I have a home internet connection provided by BT. They give me an IPv4 and an IPv6 address. Traffic preferences IPv6 where it can. How would IPv4+ be added in this scenario? Simple, a firmware update would need to be made on my router. And every router for every other BT customer. Same will apply for VirginMedia et-al. You keep saying it won?t be needed unless there is NAT, but most home routers use NAT. Please explain to me how you think Microsoft are going to spend millions on your upgrade for zero benefit to them? Please explain how ISP?s will recall and replace millions of set top boxes and modems? Please explain how upgrades are going to be done on end of life switches and routers? Please explain how every DNS server on the planet will be upgraded seamlessly? Seriously, if you are having this hard a time winning us over, you don?t stand a chance. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:37 To: Sander Steffann ; Gert D?ring Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? First there was the IPv6 fans and now there are the Spamhaus fans. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Sander Steffann > Sent: Sunday, April 26, 2020 12:28 PM To: Gert D?ring > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: >> I think it is appropriate to close this discussion here. >> Elad will eventually submit his proposed al RIPE meeting or he'll write a >> RFC. > > Basically, this. Seconded > [...] > > Overall, as long as no implementations can be provided (source code on > github etc) this sounds like a somewhat cheap shot to make people believe > you're going to solve their IPv4 problems if they just vote you to the > NCC executive board. And I hope the NCC members are smart enough to not > vote based on glorious promises, but on track record, provable background, > etc. I have contacted Elad off-list and shown him many fallacies in his design. He insisted implementation and deployment of IPv4+ was easy. I told him he is delusional and that I emailed him off-list as not to shame him publicly, and all he said was: > Go ahead, shame me publicly and you will receive the exact same answers, you are obviously have interests regarding IPv6 and you are trying to avoid from the world more IPv4 addresses just for your own personal profit. > > You are obviously have illegal interests in Ripe and this is the only reasons for your emails to me. There is no talking sense into this person. He is oblivious to how the internet works and how hardware and software upgrades are implemented and deployed. Obviously pointing out his flaws means I have an illegal interest somehow. I think Elad has already tried following Trump's recent advice and we are seeing the consequences? Time to move on? Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 11:59:49 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 09:59:49 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> References: , <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> Message-ID: Stuart, The people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Sunday, April 26, 2020 12:54 PM To: Elad Cohen ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, You are now making yourself look a little paranoid and silly. Respectfully, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:53 To: Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home? * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Sun Apr 26 12:02:23 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Sun, 26 Apr 2020 10:02:23 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426090930.GN50230@Space.Net>, , Message-ID: Elad, I am against your idea, you have not won me over and I don't think you are likely to. I have repeatedly said this will not work. It's a nice idea, and would have had promise if it was introduced before IPv6 but as things stand today, you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresses. As I said, if you are having this much trouble introducing it to us, you don't stand a chance. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 10:59 To: Stuart Willet (primary) ; Sander Steffann ; Gert D?ring Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, I don't have any trouble convincing you, the people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:46 PM To: Elad Cohen >; Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Respectfully Elad, you are pushing your idea without considering the consequences. There is no operation against you, we are just trying to point out the flaws in your idea. Just consider this, you are currently speaking with the group that will inevitably be the ones to roll out your idea. If you are having this much trouble convincing us this is a good idea, how would the rest of the world hold up? You keep saying this will work with existing IPv4 but it simply won't will it. I have a home internet connection provided by BT. They give me an IPv4 and an IPv6 address. Traffic preferences IPv6 where it can. How would IPv4+ be added in this scenario? Simple, a firmware update would need to be made on my router. And every router for every other BT customer. Same will apply for VirginMedia et-al. You keep saying it won't be needed unless there is NAT, but most home routers use NAT. Please explain to me how you think Microsoft are going to spend millions on your upgrade for zero benefit to them? Please explain how ISP's will recall and replace millions of set top boxes and modems? Please explain how upgrades are going to be done on end of life switches and routers? Please explain how every DNS server on the planet will be upgraded seamlessly? Seriously, if you are having this hard a time winning us over, you don't stand a chance. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:37 To: Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? First there was the IPv6 fans and now there are the Spamhaus fans. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Sander Steffann > Sent: Sunday, April 26, 2020 12:28 PM To: Gert D?ring > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: >> I think it is appropriate to close this discussion here. >> Elad will eventually submit his proposed al RIPE meeting or he'll write a >> RFC. > > Basically, this. Seconded > [...] > > Overall, as long as no implementations can be provided (source code on > github etc) this sounds like a somewhat cheap shot to make people believe > you're going to solve their IPv4 problems if they just vote you to the > NCC executive board. And I hope the NCC members are smart enough to not > vote based on glorious promises, but on track record, provable background, > etc. I have contacted Elad off-list and shown him many fallacies in his design. He insisted implementation and deployment of IPv4+ was easy. I told him he is delusional and that I emailed him off-list as not to shame him publicly, and all he said was: > Go ahead, shame me publicly and you will receive the exact same answers, you are obviously have interests regarding IPv6 and you are trying to avoid from the world more IPv4 addresses just for your own personal profit. > > You are obviously have illegal interests in Ripe and this is the only reasons for your emails to me. There is no talking sense into this person. He is oblivious to how the internet works and how hardware and software upgrades are implemented and deployed. Obviously pointing out his flaws means I have an illegal interest somehow. I think Elad has already tried following Trump's recent advice and we are seeing the consequences... Time to move on... Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.lanners at lu-cix.lu Sun Apr 26 12:03:22 2020 From: michel.lanners at lu-cix.lu (Michel Lanners) Date: Sun, 26 Apr 2020 12:03:22 +0200 (CEST) Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: Elad, There is no cyber influence operation against you. Even though it?s popular these days, you?re olaying Trump with the whole mailing list. I?m amazed, and you should be grateful, that there is so many positive criticism to your idea, and that it?s not just palinly dismissed. But now the discussion has wasted enough bandwidth, green energy, and time. Let it rest, take it to other people and groups as was suggested, see if you can win them over. Or put the same energy at pushing IPv6. In contrast to your idea, IPv6 is there and is a reality. End of the disucssion for me. Cheers Michel Get Outlook for iOS ________________________________ From: Elad Cohen on behalf of Elad Cohen Sent: Sunday, April 26, 2020 11:54 a.m. To: Sander Steffann Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home? * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Sun Apr 26 12:03:53 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Sun, 26 Apr 2020 10:03:53 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> Message-ID: You have not convinced me, I make no money from IPv6. I have no incentive to push IPv6 or downplay IPv4 or IPV4+ Your idea is flawed and that's that. Sorry, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:00 To: Stuart Willet (primary) ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, The people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:54 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, You are now making yourself look a little paranoid and silly. Respectfully, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:53 To: Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home... * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.gallo at lenfiber.it Sun Apr 26 12:03:54 2020 From: thomas.gallo at lenfiber.it (Thomas Gallo @ Lenfiber S.p.A.) Date: Sun, 26 Apr 2020 12:03:54 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: <678a5821-de4d-a75d-d74f-5af21c07fe11@lenfiber.it> Hi, many years ago it could have been a good idea.. but even if all of this could be implemented on the software side today... but what about ASICs and so forth? (thinking to circuitry that do lookup based on 32bits for example) Best regards, Thomas Il 26/04/2020 11:52, Elad Cohen ha scritto: > Sander is taking part in an illegal cyber influence operation against me. > > Sander, instead of lying and acting like a coward with other > interests, go ahead and ask me publicly any question that you would > like regarding IPv4+ and you will be answered. > > Respectfully, > Elad > > > ------------------------------------------------------------------------ > *From:* Sander Steffann > *Sent:* Sunday, April 26, 2020 12:40 PM > *To:* Elad Cohen > *Cc:* Gert D?ring; members-discuss at ripe.net > *Subject:* Re: [members-discuss] Technical solution to resolve the > IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 > addresses that are needed in the world > > Hi, > > > What being done here is a cyber influence operation against me, > after I'm only trying to do good to the community. > > > > Sander, you didn't mention any flaws,? can you please write them > here and I will answer each and every one of them ? > > This is not the place Elad. Many flaws have been pointed out to you > already, but you just dismiss them. Take this to the IETF, you'll feel > right at home? * > > Cheers, > Sander > > * for those who don't follow the IETF, there is an appeal ongoing > about IETF chairs and ADs ignoring inconvenient questions and objections > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/thomas.gallo%40lenfiber.it -- Thomas Gallo email: thomas.gallo at lenfiber.it Amministratore unico Lenfiber S.p.A. Centro Direzionale Interporto Padova - Torre B Galleria Spagna, 36 - 35127 Padova (PD) ph: +39 049 85 94 766 fax: +39 049 82 51 032 P.Iva/VAT: IT04669150288 Cap.Soc. 200.000,00 Euro i.v. www.lenfiber.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 12:05:45 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 10:05:45 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426090930.GN50230@Space.Net>, , , Message-ID: But you didn't understand IPv4+ based on what you are writing or you are trying to influence the readers... First fully understand something, then decide if you are against it or not. Regarding: "you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresse" No hardware upgrades will be need, only software updates and the software developers (operating system vendors and routing equipment manufacturers) will receive incentives. End-users / companies / organizations - will need to invest nothing. Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Sunday, April 26, 2020 1:02 PM To: Elad Cohen ; Sander Steffann ; Gert D?ring Cc: members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, I am against your idea, you have not won me over and I don?t think you are likely to. I have repeatedly said this will not work. It?s a nice idea, and would have had promise if it was introduced before IPv6 but as things stand today, you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresses. As I said, if you are having this much trouble introducing it to us, you don?t stand a chance. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 10:59 To: Stuart Willet (primary) ; Sander Steffann ; Gert D?ring Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, I don't have any trouble convincing you, the people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:46 PM To: Elad Cohen >; Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Respectfully Elad, you are pushing your idea without considering the consequences. There is no operation against you, we are just trying to point out the flaws in your idea. Just consider this, you are currently speaking with the group that will inevitably be the ones to roll out your idea. If you are having this much trouble convincing us this is a good idea, how would the rest of the world hold up? You keep saying this will work with existing IPv4 but it simply won?t will it. I have a home internet connection provided by BT. They give me an IPv4 and an IPv6 address. Traffic preferences IPv6 where it can. How would IPv4+ be added in this scenario? Simple, a firmware update would need to be made on my router. And every router for every other BT customer. Same will apply for VirginMedia et-al. You keep saying it won?t be needed unless there is NAT, but most home routers use NAT. Please explain to me how you think Microsoft are going to spend millions on your upgrade for zero benefit to them? Please explain how ISP?s will recall and replace millions of set top boxes and modems? Please explain how upgrades are going to be done on end of life switches and routers? Please explain how every DNS server on the planet will be upgraded seamlessly? Seriously, if you are having this hard a time winning us over, you don?t stand a chance. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:37 To: Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? First there was the IPv6 fans and now there are the Spamhaus fans. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Sander Steffann > Sent: Sunday, April 26, 2020 12:28 PM To: Gert D?ring > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: >> I think it is appropriate to close this discussion here. >> Elad will eventually submit his proposed al RIPE meeting or he'll write a >> RFC. > > Basically, this. Seconded > [...] > > Overall, as long as no implementations can be provided (source code on > github etc) this sounds like a somewhat cheap shot to make people believe > you're going to solve their IPv4 problems if they just vote you to the > NCC executive board. And I hope the NCC members are smart enough to not > vote based on glorious promises, but on track record, provable background, > etc. I have contacted Elad off-list and shown him many fallacies in his design. He insisted implementation and deployment of IPv4+ was easy. I told him he is delusional and that I emailed him off-list as not to shame him publicly, and all he said was: > Go ahead, shame me publicly and you will receive the exact same answers, you are obviously have interests regarding IPv6 and you are trying to avoid from the world more IPv4 addresses just for your own personal profit. > > You are obviously have illegal interests in Ripe and this is the only reasons for your emails to me. There is no talking sense into this person. He is oblivious to how the internet works and how hardware and software upgrades are implemented and deployed. Obviously pointing out his flaws means I have an illegal interest somehow. I think Elad has already tried following Trump's recent advice and we are seeing the consequences? Time to move on? Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at lseitz.de Sun Apr 26 12:06:19 2020 From: mail at lseitz.de (Lennart Seitz) Date: Sun, 26 Apr 2020 12:06:19 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426090930.GN50230@Space.Net> Message-ID: <3c8c3b68-ab58-87b6-1f40-f5eecf0bfa88@lseitz.de> People dont need IPv4 - people need address space, and there IS a next-gen protocol. Your idea is just a little late, lets say by 20 years :) Regards. Am 26.04.2020 um 11:58 schrieb Elad Cohen: > Stuart, > > I don't have any trouble convincing you, the people that responded are > not reflecting the opinion of the vast majority of internet companies > and internet organizations - which needs IPv4. > > Each and every person that I wasn't able to convince as you wrote is > an active deployer of IPv6 and earns his money from deploying IPv6. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* Stuart Willet (primary) > *Sent:* Sunday, April 26, 2020 12:46 PM > *To:* Elad Cohen ; Sander Steffann > ; Gert D?ring > *Cc:* members-discuss at ripe.net > *Subject:* RE: [members-discuss] Technical solution to resolve the > IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 > addresses that are needed in the world > ? > > Respectfully Elad, you are pushing your idea without considering the > consequences. > > There is no operation against you, we are just trying to point out the > flaws in your idea. > > Just consider this, you are currently speaking with the group that > will inevitably be the ones to roll out your idea. If you are having > this much trouble convincing us this is a good idea, how would the > rest of the world hold up? > > ? > > You keep saying this will work with existing IPv4 but it simply won?t > will it. > > I have a home internet connection provided by BT. They give me an IPv4 > and an IPv6 address. > > Traffic preferences IPv6 where it can. > > ? > > How would IPv4+ be added in this scenario? Simple, a firmware update > would need to be made on my router. And every router for every other > BT customer. > Same will apply for VirginMedia et-al. > > You keep saying it won?t be needed unless there is NAT, but most home > routers use NAT. > > Please explain to me how you think Microsoft are going to spend > millions on your upgrade for zero benefit to them? > Please explain how ISP?s will recall and replace millions of set top > boxes and modems? > Please explain how upgrades are going to be done on end of life > switches and routers? > > Please explain how every DNS server on the planet will be upgraded > seamlessly? > > ? > > Seriously, if you are having this hard a time winning us over, you > don?t stand a chance. > > ? > > Best, > > ? > > Stuart Willet. > > ? > > *From:*members-discuss [mailto:members-discuss-bounces at ripe.net] *On > Behalf Of *Elad Cohen > *Sent:* 26 April 2020 10:37 > *To:* Sander Steffann ; Gert D?ring > *Cc:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] Technical solution to resolve the > IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 > addresses that are needed in the world > > ? > > Hello Everyone, > > ? > > What being done here is a cyber influence operation against me, after > I'm only trying to do good to the community. > > ? > > Sander, you didn't mention any flaws,? can you please write them here > and I will answer each and every one of them ? > > ? > > First there was the IPv6 fans and now there are the Spamhaus fans. > > ? > > Respectfully, > > Elad > > ------------------------------------------------------------------------ > > *From:*members-discuss > on behalf of Sander > Steffann > > *Sent:* Sunday, April 26, 2020 12:28 PM > *To:* Gert D?ring > > *Cc:* members-discuss at ripe.net > > > *Subject:* Re: [members-discuss] Technical solution to resolve the > IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 > addresses that are needed in the world > > ? > > Hi, > > > On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: > >> I think it is appropriate to close this discussion here. > >> Elad will eventually submit his proposed al RIPE meeting or he'll > write a > >> RFC. > > > > Basically, this. > > Seconded > > > [...] > > > > Overall, as long as no implementations can be provided (source code on > > github etc) this sounds like a somewhat cheap shot to make people > believe > > you're going to solve their IPv4 problems if they just vote you to the > > NCC executive board.? And I hope the NCC members are smart enough to not > > vote based on glorious promises, but on track record, provable > background, > > etc. > > I have contacted Elad off-list and shown him many fallacies in his > design. He insisted implementation and deployment of IPv4+ was easy. I > told him he is delusional and that I emailed him off-list as not to > shame him publicly, and all he said was: > > > Go ahead, shame me publicly and you will receive the exact same > answers, you are obviously have interests regarding IPv6 and you are > trying to avoid from the world more IPv4 addresses just for your own > personal profit. > > > > You are obviously have illegal interests in Ripe and this is the > only reasons for your emails to me. > > There is no talking sense into this person. He is oblivious to how the > internet works and how hardware and software upgrades are implemented > and deployed. Obviously pointing out his flaws means I have an illegal > interest somehow. > > I think Elad has already tried following Trump's recent advice and we > are seeing the consequences? > > Time to move on? > Sander > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/mail%40lseitz.de -- Mit freundlichen Gr??en, Lennart Seitz PGP-Schl?ssel: 0x00165284eb3f775d (https://pgp.lseitz.de/key.asc) -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 12:07:24 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 10:07:24 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> , Message-ID: But you didn't understand IPv4+ based on what you are writing or you are trying to influence the readers... First fully understand something, then decide if you are against it or not. Regarding: "you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresse" No hardware upgrades will be need, only software updates and the software developers (operating system vendors and routing equipment manufacturers) will receive incentives. End-users / companies / organizations - will need to invest nothing. Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Sunday, April 26, 2020 1:03 PM To: Elad Cohen ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You have not convinced me, I make no money from IPv6. I have no incentive to push IPv6 or downplay IPv4 or IPV4+ Your idea is flawed and that?s that. Sorry, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:00 To: Stuart Willet (primary) ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, The people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:54 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, You are now making yourself look a little paranoid and silly. Respectfully, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:53 To: Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home? * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Sun Apr 26 12:07:46 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Sun, 26 Apr 2020 10:07:46 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426090930.GN50230@Space.Net>, , , Message-ID: <805bf358d1a34f50bd84d90a13887a50@safehosts.co.uk> How will you "software update" my home BT modem? How will you "software update" the end of life routing and switching equipment? And, most importantly, who will pay for development and rollout? From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:06 To: Stuart Willet (primary) ; Sander Steffann ; Gert D?ring Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world But you didn't understand IPv4+ based on what you are writing or you are trying to influence the readers... First fully understand something, then decide if you are against it or not. Regarding: "you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresse" No hardware upgrades will be need, only software updates and the software developers (operating system vendors and routing equipment manufacturers) will receive incentives. End-users / companies / organizations - will need to invest nothing. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:02 PM To: Elad Cohen >; Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, I am against your idea, you have not won me over and I don't think you are likely to. I have repeatedly said this will not work. It's a nice idea, and would have had promise if it was introduced before IPv6 but as things stand today, you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresses. As I said, if you are having this much trouble introducing it to us, you don't stand a chance. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 10:59 To: Stuart Willet (primary) >; Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, I don't have any trouble convincing you, the people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:46 PM To: Elad Cohen >; Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Respectfully Elad, you are pushing your idea without considering the consequences. There is no operation against you, we are just trying to point out the flaws in your idea. Just consider this, you are currently speaking with the group that will inevitably be the ones to roll out your idea. If you are having this much trouble convincing us this is a good idea, how would the rest of the world hold up? You keep saying this will work with existing IPv4 but it simply won't will it. I have a home internet connection provided by BT. They give me an IPv4 and an IPv6 address. Traffic preferences IPv6 where it can. How would IPv4+ be added in this scenario? Simple, a firmware update would need to be made on my router. And every router for every other BT customer. Same will apply for VirginMedia et-al. You keep saying it won't be needed unless there is NAT, but most home routers use NAT. Please explain to me how you think Microsoft are going to spend millions on your upgrade for zero benefit to them? Please explain how ISP's will recall and replace millions of set top boxes and modems? Please explain how upgrades are going to be done on end of life switches and routers? Please explain how every DNS server on the planet will be upgraded seamlessly? Seriously, if you are having this hard a time winning us over, you don't stand a chance. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:37 To: Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? First there was the IPv6 fans and now there are the Spamhaus fans. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Sander Steffann > Sent: Sunday, April 26, 2020 12:28 PM To: Gert D?ring > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: >> I think it is appropriate to close this discussion here. >> Elad will eventually submit his proposed al RIPE meeting or he'll write a >> RFC. > > Basically, this. Seconded > [...] > > Overall, as long as no implementations can be provided (source code on > github etc) this sounds like a somewhat cheap shot to make people believe > you're going to solve their IPv4 problems if they just vote you to the > NCC executive board. And I hope the NCC members are smart enough to not > vote based on glorious promises, but on track record, provable background, > etc. I have contacted Elad off-list and shown him many fallacies in his design. He insisted implementation and deployment of IPv4+ was easy. I told him he is delusional and that I emailed him off-list as not to shame him publicly, and all he said was: > Go ahead, shame me publicly and you will receive the exact same answers, you are obviously have interests regarding IPv6 and you are trying to avoid from the world more IPv4 addresses just for your own personal profit. > > You are obviously have illegal interests in Ripe and this is the only reasons for your emails to me. There is no talking sense into this person. He is oblivious to how the internet works and how hardware and software upgrades are implemented and deployed. Obviously pointing out his flaws means I have an illegal interest somehow. I think Elad has already tried following Trump's recent advice and we are seeing the consequences... Time to move on... Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Sun Apr 26 12:16:33 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Sun, 26 Apr 2020 10:16:33 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> , Message-ID: <5393a4c1038d40798cc0cf66656f83ef@safehosts.co.uk> Show me how to "software update" my BT modem to accept iPv4 (rhetorical) I'm sorry, but you have had plenty of feedback from lots of people. You refuse to see the obvious, nobody is going to spend the man hours required. I am now respectfully bowing out, I have wasted enough time on this. Please feel free to tell people I am part of an IPv6 conspiracy against you, but also accept that this is nonsense. Best regards, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:07 To: Stuart Willet (primary) ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world But you didn't understand IPv4+ based on what you are writing or you are trying to influence the readers... First fully understand something, then decide if you are against it or not. Regarding: "you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresse" No hardware upgrades will be need, only software updates and the software developers (operating system vendors and routing equipment manufacturers) will receive incentives. End-users / companies / organizations - will need to invest nothing. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:03 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You have not convinced me, I make no money from IPv6. I have no incentive to push IPv6 or downplay IPv4 or IPV4+ Your idea is flawed and that's that. Sorry, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:00 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, The people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:54 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, You are now making yourself look a little paranoid and silly. Respectfully, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:53 To: Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home... * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 12:16:33 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 10:16:33 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <805bf358d1a34f50bd84d90a13887a50@safehosts.co.uk> References: <20200426090930.GN50230@Space.Net>, , , , <805bf358d1a34f50bd84d90a13887a50@safehosts.co.uk> Message-ID: Your home BT modem doesn't need to have any software update and will work 100% with IPv4+. End of life switching equipment is layer 2 and hence not related to IP and irrelevant and will not need to to be updated at all. Regarding end of life routing equipment - if it is a router with no more than two physical routes - then it will not need to be updated at all - otherwise IT technician should do what it can in the network design for the specific marginal end of life routing equipment to have two physical routes if we want IPv4+ packets to go over properly through it, for example to switch that router with another not end-of-life router that can be upgraded while the new location of the end of life router will not have more than two physical routes. Creativity needs to come in here. This is a marginal case. Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Sunday, April 26, 2020 1:07 PM To: Elad Cohen ; Sander Steffann ; Gert D?ring Cc: members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world How will you ?software update? my home BT modem? How will you ?software update? the end of life routing and switching equipment? And, most importantly, who will pay for development and rollout? From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:06 To: Stuart Willet (primary) ; Sander Steffann ; Gert D?ring Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world But you didn't understand IPv4+ based on what you are writing or you are trying to influence the readers... First fully understand something, then decide if you are against it or not. Regarding: "you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresse" No hardware upgrades will be need, only software updates and the software developers (operating system vendors and routing equipment manufacturers) will receive incentives. End-users / companies / organizations - will need to invest nothing. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:02 PM To: Elad Cohen >; Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, I am against your idea, you have not won me over and I don?t think you are likely to. I have repeatedly said this will not work. It?s a nice idea, and would have had promise if it was introduced before IPv6 but as things stand today, you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresses. As I said, if you are having this much trouble introducing it to us, you don?t stand a chance. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 10:59 To: Stuart Willet (primary) >; Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, I don't have any trouble convincing you, the people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:46 PM To: Elad Cohen >; Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Respectfully Elad, you are pushing your idea without considering the consequences. There is no operation against you, we are just trying to point out the flaws in your idea. Just consider this, you are currently speaking with the group that will inevitably be the ones to roll out your idea. If you are having this much trouble convincing us this is a good idea, how would the rest of the world hold up? You keep saying this will work with existing IPv4 but it simply won?t will it. I have a home internet connection provided by BT. They give me an IPv4 and an IPv6 address. Traffic preferences IPv6 where it can. How would IPv4+ be added in this scenario? Simple, a firmware update would need to be made on my router. And every router for every other BT customer. Same will apply for VirginMedia et-al. You keep saying it won?t be needed unless there is NAT, but most home routers use NAT. Please explain to me how you think Microsoft are going to spend millions on your upgrade for zero benefit to them? Please explain how ISP?s will recall and replace millions of set top boxes and modems? Please explain how upgrades are going to be done on end of life switches and routers? Please explain how every DNS server on the planet will be upgraded seamlessly? Seriously, if you are having this hard a time winning us over, you don?t stand a chance. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:37 To: Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? First there was the IPv6 fans and now there are the Spamhaus fans. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Sander Steffann > Sent: Sunday, April 26, 2020 12:28 PM To: Gert D?ring > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: >> I think it is appropriate to close this discussion here. >> Elad will eventually submit his proposed al RIPE meeting or he'll write a >> RFC. > > Basically, this. Seconded > [...] > > Overall, as long as no implementations can be provided (source code on > github etc) this sounds like a somewhat cheap shot to make people believe > you're going to solve their IPv4 problems if they just vote you to the > NCC executive board. And I hope the NCC members are smart enough to not > vote based on glorious promises, but on track record, provable background, > etc. I have contacted Elad off-list and shown him many fallacies in his design. He insisted implementation and deployment of IPv4+ was easy. I told him he is delusional and that I emailed him off-list as not to shame him publicly, and all he said was: > Go ahead, shame me publicly and you will receive the exact same answers, you are obviously have interests regarding IPv6 and you are trying to avoid from the world more IPv4 addresses just for your own personal profit. > > You are obviously have illegal interests in Ripe and this is the only reasons for your emails to me. There is no talking sense into this person. He is oblivious to how the internet works and how hardware and software upgrades are implemented and deployed. Obviously pointing out his flaws means I have an illegal interest somehow. I think Elad has already tried following Trump's recent advice and we are seeing the consequences? Time to move on? Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 12:18:21 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 10:18:21 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <5393a4c1038d40798cc0cf66656f83ef@safehosts.co.uk> References: , <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> , , <5393a4c1038d40798cc0cf66656f83ef@safehosts.co.uk> Message-ID: I already answered to you one minute ago. No software update will need to be done to any modem, I wrote it many many times but you ignored it - so please don't blame it on me. Here is again: Any home modem will not need to be updated at all Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Sunday, April 26, 2020 1:16 PM To: Elad Cohen ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Show me how to ?software update? my BT modem to accept iPv4 (rhetorical) I?m sorry, but you have had plenty of feedback from lots of people. You refuse to see the obvious, nobody is going to spend the man hours required. I am now respectfully bowing out, I have wasted enough time on this. Please feel free to tell people I am part of an IPv6 conspiracy against you, but also accept that this is nonsense. Best regards, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:07 To: Stuart Willet (primary) ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world But you didn't understand IPv4+ based on what you are writing or you are trying to influence the readers... First fully understand something, then decide if you are against it or not. Regarding: "you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresse" No hardware upgrades will be need, only software updates and the software developers (operating system vendors and routing equipment manufacturers) will receive incentives. End-users / companies / organizations - will need to invest nothing. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:03 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You have not convinced me, I make no money from IPv6. I have no incentive to push IPv6 or downplay IPv4 or IPV4+ Your idea is flawed and that?s that. Sorry, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:00 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, The people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:54 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, You are now making yourself look a little paranoid and silly. Respectfully, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:53 To: Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home? * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 12:38:01 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 10:38:01 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <678a5821-de4d-a75d-d74f-5af21c07fe11@lenfiber.it> References: , <678a5821-de4d-a75d-d74f-5af21c07fe11@lenfiber.it> Message-ID: ASICs or any device with a similar problem, can be connected to the internet through a NAT router, the NAT router will help the ASIC or the similar device with IPv4+ (The ASIC or the similar device will only be able to initiate connections to IPv4, but any ip addresses in the internet - IPv4 or IPv4+ will be able to initiate a connection to the ASIC or the similar device and then to create a session with it, the NAT router will monitor the session and will set the IPv4+ bits accordingly) In advanced configuration in the NAT router there can be an option that all ip packets that will originate from the specific ASIC will be only to IPv4+ addresses (and not to IPv4) so the NAT router will always set the IPv4+ related bits in any ip packet originated from the ASIC or similar device. Respectfully, Elad ________________________________ From: members-discuss on behalf of Thomas Gallo @ Lenfiber S.p.A. Sent: Sunday, April 26, 2020 1:03 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, many years ago it could have been a good idea.. but even if all of this could be implemented on the software side today... but what about ASICs and so forth? (thinking to circuitry that do lookup based on 32bits for example) Best regards, Thomas Il 26/04/2020 11:52, Elad Cohen ha scritto: Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home? * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/thomas.gallo%40lenfiber.it -- Thomas Gallo email: thomas.gallo at lenfiber.it Amministratore unico Lenfiber S.p.A. Centro Direzionale Interporto Padova - Torre B Galleria Spagna, 36 - 35127 Padova (PD) ph: +39 049 85 94 766 fax: +39 049 82 51 032 P.Iva/VAT: IT04669150288 Cap.Soc. 200.000,00 Euro i.v. www.lenfiber.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at fiberdirekt.se Sun Apr 26 12:39:10 2020 From: peter at fiberdirekt.se (Peter Linder) Date: Sun, 26 Apr 2020 12:39:10 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426090930.GN50230@Space.Net>, , Message-ID: Serveral varieties of this idea was proposed when Ipv6 was bring discussed decades ago. There was even some patenting going on. Those ideas were discarded then and this has no chance today. "Stuart Willet (primary)" skrev: (26 april 2020 12:02:23 CEST) >Elad, > >I am against your idea, you have not won me over and I don't think you >are likely to. >I have repeatedly said this will not work. > >It's a nice idea, and would have had promise if it was introduced >before IPv6 but as things stand today, you want millions of dollars >spent on millions of upgrades for a handful of new IPv4 addresses. > >As I said, if you are having this much trouble introducing it to us, >you don't stand a chance. > > >Best, > >Stuart Willet. > >From: Elad Cohen [mailto:elad at netstyle.io] >Sent: 26 April 2020 10:59 >To: Stuart Willet (primary) ; Sander Steffann >; Gert D?ring >Cc: members-discuss at ripe.net >Subject: Re: [members-discuss] Technical solution to resolve the IPv4 >Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that >are needed in the world > >Stuart, > >I don't have any trouble convincing you, the people that responded are >not reflecting the opinion of the vast majority of internet companies >and internet organizations - which needs IPv4. > >Each and every person that I wasn't able to convince as you wrote is an >active deployer of IPv6 and earns his money from deploying IPv6. > >Respectfully, >Elad >________________________________ >From: Stuart Willet (primary) >> >Sent: Sunday, April 26, 2020 12:46 PM >To: Elad Cohen >; Sander >Steffann >; Gert D?ring >> >Cc: members-discuss at ripe.net >> >Subject: RE: [members-discuss] Technical solution to resolve the IPv4 >Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that >are needed in the world > > >Respectfully Elad, you are pushing your idea without considering the >consequences. > >There is no operation against you, we are just trying to point out the >flaws in your idea. > >Just consider this, you are currently speaking with the group that will >inevitably be the ones to roll out your idea. If you are having this >much trouble convincing us this is a good idea, how would the rest of >the world hold up? > > > >You keep saying this will work with existing IPv4 but it simply won't >will it. > >I have a home internet connection provided by BT. They give me an IPv4 >and an IPv6 address. > >Traffic preferences IPv6 where it can. > > > >How would IPv4+ be added in this scenario? Simple, a firmware update >would need to be made on my router. And every router for every other BT >customer. >Same will apply for VirginMedia et-al. > >You keep saying it won't be needed unless there is NAT, but most home >routers use NAT. > >Please explain to me how you think Microsoft are going to spend >millions on your upgrade for zero benefit to them? >Please explain how ISP's will recall and replace millions of set top >boxes and modems? >Please explain how upgrades are going to be done on end of life >switches and routers? > >Please explain how every DNS server on the planet will be upgraded >seamlessly? > > > >Seriously, if you are having this hard a time winning us over, you >don't stand a chance. > > > >Best, > > > >Stuart Willet. > > > >From: members-discuss [mailto:members-discuss-bounces at ripe.net] On >Behalf Of Elad Cohen >Sent: 26 April 2020 10:37 >To: Sander Steffann >; >Gert D?ring > >Cc: members-discuss at ripe.net >Subject: Re: [members-discuss] Technical solution to resolve the IPv4 >Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that >are needed in the world > > > >Hello Everyone, > > > >What being done here is a cyber influence operation against me, after >I'm only trying to do good to the community. > > > >Sander, you didn't mention any flaws, can you please write them here >and I will answer each and every one of them ? > > > >First there was the IPv6 fans and now there are the Spamhaus fans. > > > >Respectfully, > >Elad > >________________________________ > >From: members-discuss >> >on behalf of Sander Steffann >> >Sent: Sunday, April 26, 2020 12:28 PM >To: Gert D?ring > >Cc: members-discuss at ripe.net >> >Subject: Re: [members-discuss] Technical solution to resolve the IPv4 >Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that >are needed in the world > > > >Hi, > >> On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: >>> I think it is appropriate to close this discussion here. >>> Elad will eventually submit his proposed al RIPE meeting or he'll >write a >>> RFC. >> >> Basically, this. > >Seconded > >> [...] >> >> Overall, as long as no implementations can be provided (source code >on >> github etc) this sounds like a somewhat cheap shot to make people >believe >> you're going to solve their IPv4 problems if they just vote you to >the >> NCC executive board. And I hope the NCC members are smart enough to >not >> vote based on glorious promises, but on track record, provable >background, >> etc. > >I have contacted Elad off-list and shown him many fallacies in his >design. He insisted implementation and deployment of IPv4+ was easy. I >told him he is delusional and that I emailed him off-list as not to >shame him publicly, and all he said was: > >> Go ahead, shame me publicly and you will receive the exact same >answers, you are obviously have interests regarding IPv6 and you are >trying to avoid from the world more IPv4 addresses just for your own >personal profit. >> >> You are obviously have illegal interests in Ripe and this is the only >reasons for your emails to me. > >There is no talking sense into this person. He is oblivious to how the >internet works and how hardware and software upgrades are implemented >and deployed. Obviously pointing out his flaws means I have an illegal >interest somehow. > >I think Elad has already tried following Trump's recent advice and we >are seeing the consequences... > >Time to move on... >Sander -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 12:42:24 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 10:42:24 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426090930.GN50230@Space.Net>, , , Message-ID: Peter, I didn't see what I wrote anywhere else, can you provide a link? Respectfully, Elad ________________________________ From: Peter Linder Sent: Sunday, April 26, 2020 1:39 PM To: members-discuss at ripe.net ; Stuart Willet (primary) ; Elad Cohen ; Sander Steffann ; Gert D?ring Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Serveral varieties of this idea was proposed when Ipv6 was bring discussed decades ago. There was even some patenting going on. Those ideas were discarded then and this has no chance today. "Stuart Willet (primary)" skrev: (26 april 2020 12:02:23 CEST) Elad, I am against your idea, you have not won me over and I don?t think you are likely to. I have repeatedly said this will not work. It?s a nice idea, and would have had promise if it was introduced before IPv6 but as things stand today, you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresses. As I said, if you are having this much trouble introducing it to us, you don?t stand a chance. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 10:59 To: Stuart Willet (primary) ; Sander Steffann ; Gert D?ring Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, I don't have any trouble convincing you, the people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:46 PM To: Elad Cohen >; Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Respectfully Elad, you are pushing your idea without considering the consequences. There is no operation against you, we are just trying to point out the flaws in your idea. Just consider this, you are currently speaking with the group that will inevitably be the ones to roll out your idea. If you are having this much trouble convincing us this is a good idea, how would the rest of the world hold up? You keep saying this will work with existing IPv4 but it simply won?t will it. I have a home internet connection provided by BT. They give me an IPv4 and an IPv6 address. Traffic preferences IPv6 where it can. How would IPv4+ be added in this scenario? Simple, a firmware update would need to be made on my router. And every router for every other BT customer. Same will apply for VirginMedia et-al. You keep saying it won?t be needed unless there is NAT, but most home routers use NAT. Please explain to me how you think Microsoft are going to spend millions on your upgrade for zero benefit to them? Please explain how ISP?s will recall and replace millions of set top boxes and modems? Please explain how upgrades are going to be done on end of life switches and routers? Please explain how every DNS server on the planet will be upgraded seamlessly? Seriously, if you are having this hard a time winning us over, you don?t stand a chance. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:37 To: Sander Steffann >; Gert D?ring > Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hello Everyone, What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? First there was the IPv6 fans and now there are the Spamhaus fans. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Sander Steffann > Sent: Sunday, April 26, 2020 12:28 PM To: Gert D?ring > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: >> I think it is appropriate to close this discussion here. >> Elad will eventually submit his proposed al RIPE meeting or he'll write a >> RFC. > > Basically, this. Seconded > [...] > > Overall, as long as no implementations can be provided (source code on > github etc) this sounds like a somewhat cheap shot to make people believe > you're going to solve their IPv4 problems if they just vote you to the > NCC executive board. And I hope the NCC members are smart enough to not > vote based on glorious promises, but on track record, provable background, > etc. I have contacted Elad off-list and shown him many fallacies in his design. He insisted implementation and deployment of IPv4+ was easy. I told him he is delusional and that I emailed him off-list as not to shame him publicly, and all he said was: > Go ahead, shame me publicly and you will receive the exact same answers, you are obviously have interests regarding IPv6 and you are trying to avoid from the world more IPv4 addresses just for your own personal profit. > > You are obviously have illegal interests in Ripe and this is the only reasons for your emails to me. There is no talking sense into this person. He is oblivious to how the internet works and how hardware and software upgrades are implemented and deployed. Obviously pointing out his flaws means I have an illegal interest somehow. I think Elad has already tried following Trump's recent advice and we are seeing the consequences? Time to move on? Sander -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at liopen.fr Sun Apr 26 12:42:28 2020 From: ripe at liopen.fr (Denis Fondras) Date: Sun, 26 Apr 2020 12:42:28 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: <20200426104228.GL90387@carcass.ledeuns.net> Claiming it is "easy" to implement is no enough. Please show us a working implementation (a proof of concept), it should not be hard. Or is it hard for you but easy for anyone else to do ? If so, it shows that you don't have a clue what you are talking about. I find that a bit sad. In France, we call people like you "Yakafokon". It means that talk is cheap, you have a supposed solution but will let others deal with the dirty work. You will not convince any of us with words. Roll up their sleeves and show us that it works somewhere else than your own mind (any supporter of your idea can join). The idea of using "unused" fields in the IPv4 header to extend adressing space is not new, it has been discussed multiple times everywhere on the Internet. We have never seen a single working implementation. You can still believe it is because the "IPv6 sect" has been actively undermining the work... For anyone claiming to have a solution for the "IPv4 exhaustion problem", do your homework before wasting the time of hundreds of mailing list participants. Thank you in advance. From stu at safehosts.co.uk Sun Apr 26 12:48:32 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Sun, 26 Apr 2020 10:48:32 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> , , <5393a4c1038d40798cc0cf66656f83ef@safehosts.co.uk> Message-ID: <5fea3db6d3ab4b2bb08af999625b0238@safehosts.co.uk> You keep saying "Any home modem will not need to be updated at all" and you keep saying switches are L2. My home modem is a L3 device. There are a lot of L3 switches which have hit end of life in lots of data centres around the world. Regardless of how many times you SAY these are L2 switches, they are not. By way of example, here is just a handful of Cisco's EOL Layer 3 (IP based) devices which would need some kind of upgrade or replacement: Cisco 6000 Series IP DSL Switches Cisco Blade Switches for Dell Cisco Blade Switches for HP Cisco Catalyst 3750 Series Switches Cisco Catalyst 3750-X Series Switches Cisco Catalyst 3560 Series Switches Cisco Catalyst 3560-C Series Switches Cisco Catalyst 3560-X Series Switches Cisco Catalyst 2960 Series Switches Cisco Catalyst 2960-S Series Switches Cisco Catalyst 2960-SF Series Switches Cisco Catalyst 2955 Series Switches Cisco Catalyst 2360 Series Switches Cisco Energy Management Suite Cisco ME 4600 Series Multiservice Optical Access Platform Cisco ME 3800X Series Carrier Ethernet Switch Routers Cisco ME 3600X Series Ethernet Access Switches Cisco ME 3400E Series Ethernet Access Switches Cisco ME 2600X Series Ethernet Access Switches Cisco Nexus 4000 Series Switches Cisco Nexus 1100 Series Cloud Services Platforms Cisco Small Business 500 Series Stackable Managed Switches Cisco Small Business 100 Series Unmanaged Switches Cisco Switch Modules for IBM Cisco Virtual Application Cloud Segmentation (VACS) Services Citrix NetScaler 1000V Remember, this is only Cisco and only a partial list. You will need to add Juniper, HP, Dell, D-Link, Alcatel, Foundry, Marconi, Nortel and many many more. You will also need to update EVERY distro of Linux, Unix, Windows and other more bespoke operating systems. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:18 To: Stuart Willet (primary) ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world I already answered to you one minute ago. No software update will need to be done to any modem, I wrote it many many times but you ignored it - so please don't blame it on me. Here is again: Any home modem will not need to be updated at all Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:16 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Show me how to "software update" my BT modem to accept iPv4 (rhetorical) I'm sorry, but you have had plenty of feedback from lots of people. You refuse to see the obvious, nobody is going to spend the man hours required. I am now respectfully bowing out, I have wasted enough time on this. Please feel free to tell people I am part of an IPv6 conspiracy against you, but also accept that this is nonsense. Best regards, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:07 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world But you didn't understand IPv4+ based on what you are writing or you are trying to influence the readers... First fully understand something, then decide if you are against it or not. Regarding: "you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresse" No hardware upgrades will be need, only software updates and the software developers (operating system vendors and routing equipment manufacturers) will receive incentives. End-users / companies / organizations - will need to invest nothing. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:03 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You have not convinced me, I make no money from IPv6. I have no incentive to push IPv6 or downplay IPv4 or IPV4+ Your idea is flawed and that's that. Sorry, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:00 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, The people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:54 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, You are now making yourself look a little paranoid and silly. Respectfully, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:53 To: Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home... * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at fiberdirekt.se Sun Apr 26 12:49:02 2020 From: peter at fiberdirekt.se (Peter Linder) Date: Sun, 26 Apr 2020 12:49:02 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426090930.GN50230@Space.Net>, , , Message-ID: <5CA599DF-725A-4665-9422-30E7E2979551@fiberdirekt.se> Elad, You must know that all routing on the isp level is done in dedicated hardware with specifically made chips. These routers will all need new line cards at the minimum. Elad Cohen skrev: (26 april 2020 12:05:45 CEST) >But you didn't understand IPv4+ based on what you are writing or you >are trying to influence the readers... > >First fully understand something, then decide if you are against it or >not. > >Regarding: >"you want millions of dollars spent on millions of upgrades for a >handful of new IPv4 addresse" > >No hardware upgrades will be need, only software updates and the >software developers (operating system vendors and routing equipment >manufacturers) will receive incentives. End-users / companies / >organizations - will need to invest nothing. > >Respectfully, >Elad >________________________________ >From: Stuart Willet (primary) >Sent: Sunday, April 26, 2020 1:02 PM >To: Elad Cohen ; Sander Steffann >; Gert D?ring >Cc: members-discuss at ripe.net >Subject: RE: [members-discuss] Technical solution to resolve the IPv4 >Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that >are needed in the world > > >Elad, > > > >I am against your idea, you have not won me over and I don?t think you >are likely to. > >I have repeatedly said this will not work. > > > >It?s a nice idea, and would have had promise if it was introduced >before IPv6 but as things stand today, you want millions of dollars >spent on millions of upgrades for a handful of new IPv4 addresses. > > > >As I said, if you are having this much trouble introducing it to us, >you don?t stand a chance. > > > > > >Best, > > > >Stuart Willet. > > > >From: Elad Cohen [mailto:elad at netstyle.io] >Sent: 26 April 2020 10:59 >To: Stuart Willet (primary) ; Sander Steffann >; Gert D?ring >Cc: members-discuss at ripe.net >Subject: Re: [members-discuss] Technical solution to resolve the IPv4 >Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that >are needed in the world > > > >Stuart, > > > >I don't have any trouble convincing you, the people that responded are >not reflecting the opinion of the vast majority of internet companies >and internet organizations - which needs IPv4. > > > >Each and every person that I wasn't able to convince as you wrote is an >active deployer of IPv6 and earns his money from deploying IPv6. > > > >Respectfully, > >Elad > >________________________________ > >From: Stuart Willet (primary) >> >Sent: Sunday, April 26, 2020 12:46 PM >To: Elad Cohen >; Sander >Steffann >; Gert D?ring >> >Cc: members-discuss at ripe.net >> >Subject: RE: [members-discuss] Technical solution to resolve the IPv4 >Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that >are needed in the world > > > >Respectfully Elad, you are pushing your idea without considering the >consequences. > >There is no operation against you, we are just trying to point out the >flaws in your idea. > >Just consider this, you are currently speaking with the group that will >inevitably be the ones to roll out your idea. If you are having this >much trouble convincing us this is a good idea, how would the rest of >the world hold up? > > > >You keep saying this will work with existing IPv4 but it simply won?t >will it. > >I have a home internet connection provided by BT. They give me an IPv4 >and an IPv6 address. > >Traffic preferences IPv6 where it can. > > > >How would IPv4+ be added in this scenario? Simple, a firmware update >would need to be made on my router. And every router for every other BT >customer. >Same will apply for VirginMedia et-al. > >You keep saying it won?t be needed unless there is NAT, but most home >routers use NAT. > >Please explain to me how you think Microsoft are going to spend >millions on your upgrade for zero benefit to them? >Please explain how ISP?s will recall and replace millions of set top >boxes and modems? >Please explain how upgrades are going to be done on end of life >switches and routers? > >Please explain how every DNS server on the planet will be upgraded >seamlessly? > > > >Seriously, if you are having this hard a time winning us over, you >don?t stand a chance. > > > >Best, > > > >Stuart Willet. > > > >From: members-discuss [mailto:members-discuss-bounces at ripe.net] On >Behalf Of Elad Cohen >Sent: 26 April 2020 10:37 >To: Sander Steffann >; >Gert D?ring > >Cc: members-discuss at ripe.net >Subject: Re: [members-discuss] Technical solution to resolve the IPv4 >Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that >are needed in the world > > > >Hello Everyone, > > > >What being done here is a cyber influence operation against me, after >I'm only trying to do good to the community. > > > >Sander, you didn't mention any flaws, can you please write them here >and I will answer each and every one of them ? > > > >First there was the IPv6 fans and now there are the Spamhaus fans. > > > >Respectfully, > >Elad > >________________________________ > >From: members-discuss >> >on behalf of Sander Steffann >> >Sent: Sunday, April 26, 2020 12:28 PM >To: Gert D?ring > >Cc: members-discuss at ripe.net >> >Subject: Re: [members-discuss] Technical solution to resolve the IPv4 >Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that >are needed in the world > > > >Hi, > >> On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: >>> I think it is appropriate to close this discussion here. >>> Elad will eventually submit his proposed al RIPE meeting or he'll >write a >>> RFC. >> >> Basically, this. > >Seconded > >> [...] >> >> Overall, as long as no implementations can be provided (source code >on >> github etc) this sounds like a somewhat cheap shot to make people >believe >> you're going to solve their IPv4 problems if they just vote you to >the >> NCC executive board. And I hope the NCC members are smart enough to >not >> vote based on glorious promises, but on track record, provable >background, >> etc. > >I have contacted Elad off-list and shown him many fallacies in his >design. He insisted implementation and deployment of IPv4+ was easy. I >told him he is delusional and that I emailed him off-list as not to >shame him publicly, and all he said was: > >> Go ahead, shame me publicly and you will receive the exact same >answers, you are obviously have interests regarding IPv6 and you are >trying to avoid from the world more IPv4 addresses just for your own >personal profit. >> >> You are obviously have illegal interests in Ripe and this is the only >reasons for your emails to me. > >There is no talking sense into this person. He is oblivious to how the >internet works and how hardware and software upgrades are implemented >and deployed. Obviously pointing out his flaws means I have an illegal >interest somehow. > >I think Elad has already tried following Trump's recent advice and we >are seeing the consequences? > >Time to move on? >Sander -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 12:52:15 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 10:52:15 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <5fea3db6d3ab4b2bb08af999625b0238@safehosts.co.uk> References: , <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> , , <5393a4c1038d40798cc0cf66656f83ef@safehosts.co.uk> , <5fea3db6d3ab4b2bb08af999625b0238@safehosts.co.uk> Message-ID: Any home-modem will not need to be updated (no matter if it is L2 or L3). Regarding the EOL list you provided, Cisco will be part of the round table (just like any other routing equipment manufacturer) and firmware upgrades will be provided by any round table member even for its EOL products so the deployment of IPv4+ will be possible. Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Sunday, April 26, 2020 1:48 PM To: Elad Cohen ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You keep saying ?Any home modem will not need to be updated at all? and you keep saying switches are L2. My home modem is a L3 device. There are a lot of L3 switches which have hit end of life in lots of data centres around the world. Regardless of how many times you SAY these are L2 switches, they are not. By way of example, here is just a handful of Cisco?s EOL Layer 3 (IP based) devices which would need some kind of upgrade or replacement: Cisco 6000 Series IP DSL Switches Cisco Blade Switches for Dell Cisco Blade Switches for HP Cisco Catalyst 3750 Series Switches Cisco Catalyst 3750-X Series Switches Cisco Catalyst 3560 Series Switches Cisco Catalyst 3560-C Series Switches Cisco Catalyst 3560-X Series Switches Cisco Catalyst 2960 Series Switches Cisco Catalyst 2960-S Series Switches Cisco Catalyst 2960-SF Series Switches Cisco Catalyst 2955 Series Switches Cisco Catalyst 2360 Series Switches Cisco Energy Management Suite Cisco ME 4600 Series Multiservice Optical Access Platform Cisco ME 3800X Series Carrier Ethernet Switch Routers Cisco ME 3600X Series Ethernet Access Switches Cisco ME 3400E Series Ethernet Access Switches Cisco ME 2600X Series Ethernet Access Switches Cisco Nexus 4000 Series Switches Cisco Nexus 1100 Series Cloud Services Platforms Cisco Small Business 500 Series Stackable Managed Switches Cisco Small Business 100 Series Unmanaged Switches Cisco Switch Modules for IBM Cisco Virtual Application Cloud Segmentation (VACS) Services Citrix NetScaler 1000V Remember, this is only Cisco and only a partial list. You will need to add Juniper, HP, Dell, D-Link, Alcatel, Foundry, Marconi, Nortel and many many more. You will also need to update EVERY distro of Linux, Unix, Windows and other more bespoke operating systems. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:18 To: Stuart Willet (primary) ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world I already answered to you one minute ago. No software update will need to be done to any modem, I wrote it many many times but you ignored it - so please don't blame it on me. Here is again: Any home modem will not need to be updated at all Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:16 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Show me how to ?software update? my BT modem to accept iPv4 (rhetorical) I?m sorry, but you have had plenty of feedback from lots of people. You refuse to see the obvious, nobody is going to spend the man hours required. I am now respectfully bowing out, I have wasted enough time on this. Please feel free to tell people I am part of an IPv6 conspiracy against you, but also accept that this is nonsense. Best regards, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:07 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world But you didn't understand IPv4+ based on what you are writing or you are trying to influence the readers... First fully understand something, then decide if you are against it or not. Regarding: "you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresse" No hardware upgrades will be need, only software updates and the software developers (operating system vendors and routing equipment manufacturers) will receive incentives. End-users / companies / organizations - will need to invest nothing. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:03 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You have not convinced me, I make no money from IPv6. I have no incentive to push IPv6 or downplay IPv4 or IPV4+ Your idea is flawed and that?s that. Sorry, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:00 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, The people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:54 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, You are now making yourself look a little paranoid and silly. Respectfully, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:53 To: Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home? * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Sun Apr 26 12:56:11 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Sun, 26 Apr 2020 10:56:11 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> , , <5393a4c1038d40798cc0cf66656f83ef@safehosts.co.uk> , <5fea3db6d3ab4b2bb08af999625b0238@safehosts.co.uk> Message-ID: <66e746fe7a2347aa949052fab698da45@safehosts.co.uk> You STILL don't see the issue? Who is going to pay for all the development? How will Cisco provide updates for EOL kit? This is ONLY a partial list of Cisco kit. There will be thousands of devices from different suppliers which are EOL and will need someone to work out how to update them. This would cost millions of dollars to do worldwide, it just isn't practical. If providers have not implemented IPv6 on EOL devices, why on earth would they implement IPv4+? EOL = End Of Life, unsupported. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:52 To: Stuart Willet (primary) ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Any home-modem will not need to be updated (no matter if it is L2 or L3). Regarding the EOL list you provided, Cisco will be part of the round table (just like any other routing equipment manufacturer) and firmware upgrades will be provided by any round table member even for its EOL products so the deployment of IPv4+ will be possible. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:48 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You keep saying "Any home modem will not need to be updated at all" and you keep saying switches are L2. My home modem is a L3 device. There are a lot of L3 switches which have hit end of life in lots of data centres around the world. Regardless of how many times you SAY these are L2 switches, they are not. By way of example, here is just a handful of Cisco's EOL Layer 3 (IP based) devices which would need some kind of upgrade or replacement: Cisco 6000 Series IP DSL Switches Cisco Blade Switches for Dell Cisco Blade Switches for HP Cisco Catalyst 3750 Series Switches Cisco Catalyst 3750-X Series Switches Cisco Catalyst 3560 Series Switches Cisco Catalyst 3560-C Series Switches Cisco Catalyst 3560-X Series Switches Cisco Catalyst 2960 Series Switches Cisco Catalyst 2960-S Series Switches Cisco Catalyst 2960-SF Series Switches Cisco Catalyst 2955 Series Switches Cisco Catalyst 2360 Series Switches Cisco Energy Management Suite Cisco ME 4600 Series Multiservice Optical Access Platform Cisco ME 3800X Series Carrier Ethernet Switch Routers Cisco ME 3600X Series Ethernet Access Switches Cisco ME 3400E Series Ethernet Access Switches Cisco ME 2600X Series Ethernet Access Switches Cisco Nexus 4000 Series Switches Cisco Nexus 1100 Series Cloud Services Platforms Cisco Small Business 500 Series Stackable Managed Switches Cisco Small Business 100 Series Unmanaged Switches Cisco Switch Modules for IBM Cisco Virtual Application Cloud Segmentation (VACS) Services Citrix NetScaler 1000V Remember, this is only Cisco and only a partial list. You will need to add Juniper, HP, Dell, D-Link, Alcatel, Foundry, Marconi, Nortel and many many more. You will also need to update EVERY distro of Linux, Unix, Windows and other more bespoke operating systems. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:18 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world I already answered to you one minute ago. No software update will need to be done to any modem, I wrote it many many times but you ignored it - so please don't blame it on me. Here is again: Any home modem will not need to be updated at all Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:16 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Show me how to "software update" my BT modem to accept iPv4 (rhetorical) I'm sorry, but you have had plenty of feedback from lots of people. You refuse to see the obvious, nobody is going to spend the man hours required. I am now respectfully bowing out, I have wasted enough time on this. Please feel free to tell people I am part of an IPv6 conspiracy against you, but also accept that this is nonsense. Best regards, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:07 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world But you didn't understand IPv4+ based on what you are writing or you are trying to influence the readers... First fully understand something, then decide if you are against it or not. Regarding: "you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresse" No hardware upgrades will be need, only software updates and the software developers (operating system vendors and routing equipment manufacturers) will receive incentives. End-users / companies / organizations - will need to invest nothing. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:03 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You have not convinced me, I make no money from IPv6. I have no incentive to push IPv6 or downplay IPv4 or IPV4+ Your idea is flawed and that's that. Sorry, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:00 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, The people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:54 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, You are now making yourself look a little paranoid and silly. Respectfully, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:53 To: Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home... * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksi at magnacapax.fi Sun Apr 26 12:49:51 2020 From: aleksi at magnacapax.fi (Aleksi) Date: Sun, 26 Apr 2020 13:49:51 +0300 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <36b7b7c6-0762-0fb7-769f-0a264429ff89@magnacapax.fi> Message-ID: <6c57b8e2-613d-c592-e7be-b8f552eeccc8@magnacapax.fi> Hi, "Where is the space in the header ? there isn't any reliable space in the header to increase the source address number or the destination address number" ?There is place in the same places you suggest in your "IPv4+" proposal ;) Quite frankly, it's been nearly 10 years since i looked into this and i do not deal at *that* level often, but i do recall there being possibility to add the few bytes required to header, instead of data segment. Quite frankly, it *does not* matter where in the packet that data is -- what matter is *most convenient* position. This is a technical detail which can be solved by those far more knowleadgable than i am on every single nuance -- I am not qualified to decide this nor does it need to be decided now. "In order for the router to look at the 2 additional bytes, the router will need to have its firmware upgrade, so every LAN router in the world will need to have its firmware upgrade." Incorrect! Only end points like i said. Instead of going on full attack mode instantly, perhaps try to read and comprehend and work with others. You complain you are being attacked, but what i see you are acting a bit like that yourself. Instead of attacking and complaining, people should try to work together by sharing ideas to get to the best possible outcome. Not "My Way or No Way!" mentality. Whatever the chosen location for the 2 or 4 additional bytes which does not get "scrubbed" on route only the end points need to support those. Route like normal, no changes, traverse like normal, until you get to the 11.11.12.1 which needs to understand beyond this, same with everything after that. "firmware-upgrade all the routers in the world - an impossible task" But magically possible for your IPv4+ proposal, just not my call it "IPv4e" as in IPv4 extended. Not a problem at all to make every single device support in the world support when it is your proposal? Also not required on "IPV4e". Hell, even not all clients do not need to understand on IPv4e the extension. On outgoing packets (from 11.11.12.1.1.1) non-enabled device sees a packet from 11.11.12.1 and responds to it normally, with NAT like code can handle the extension translation on the 11.11.12.1 switch :) Albeit granted non-enabled end device will need network stack code updated to open directly a connection with extended address, but vice-versa it's not requirement. ZERO BGP changes required. ZERO routing changes. Extensions would always be considered L2 on grander scale, and the extension cannot be split (avoids more routing table fragmentation and growth). Within the extension routing can still be done, no need to have all the extension in single subnet, just not on the grander scale. Needed upgrades: End point switch/router where extension begins, and switches and devices behind that. ie. only accrue cost and hassle for the amount you want to extend to -- and only for new installs. Let's be real here tho, a decade old switch *will* not get an update like this, nor might have the power to do the additional lookups, but you do not need to update your whole network at once -- only where you want to use this. Essentially you can decide whether or not to extend from /32 at all, or full /16 worth of addresses. Hell, if you want you can only use it on single device to map every software on their own IP instead of just port or something interesting like that :) Or you can have /16 worth of devices beyond it. All up to the end point! Speaking of which mobile networks now relying on NAT could additionally offer extended IP to end devices, in case the device supports it and needs direct connectivity. Same for all other NAT networks out there. Clients will need software updates to access these more or less, but there will always be potential for partial connectivity even on non supported devices, without any work for the client side. There will always be devices running Windows XP still. There will always be super old non-updated legacy devices, no matter what route you take. As there is no additional cost for client, server, BGP level etc. it could start to begin slowly by those who most needs it and adoption would grow slowly over time, which increases level of connectivity. There is after all connectivity between regular IPv4 and an extended one. Typical office PC, mobile device etc. will get quick updates however typically, so getting a huge number of supported devices online will happen relatively quick (1 year?) -- all is needed Linux kernel update, and microsoft and apple to do the same and eventually you will have vast majority of devices supported with no additional changes -- no need to change switches, firewalls etc. So this would end up being more of a software engineering exercise than wholesale router upgrades at huge scale. Router manufacturers will probably be happy to support as they get to sell more hardware then, or even justify significantly higher cost for IPv4e devices ;) So from my perspective, i see very little friction to do something like this -- everyone wins and it's quite minimal effort to implement or not to implement in most use cases. -Aleksi On 4/26/20 12:57 AM, Elad Cohen wrote: > Aleksei, > > Regarding: > "Server (11.11.11.1) sends packet with additional header data (there > is space for this!)" > > Where is the space in the header ? there isn't any reliable space in > the header to increase the source address number or the destination > address number > > Where in the ip header are the two additional bytes for the source > address and the two additional bytes for the destination address ? > > Regarding: > "Router at 11.11.12.1 gets this packet, looks inside the header and > notices the 2 additional bytes and forwards this to client at LOCAL > 11.11.12.1.1.1 (L2 lookup)" > > In order for the router to look at the 2 additional bytes, the router > will need to have its firmware upgrade, so every LAN router in the > world will need to have its firmware upgrade. > > In case you will explain where are the additional two bytes for the > source address and the destination address (there isn't any reliable > place, many routers will drop the ip packet due to it unless you will > firmware-upgrade all the routers in the world - an impossible task) - > then the additional ip addresses are only for current existing LANs > (new ASNs will need to have ip addresses from the first /32 which do > not exist due to the lack of IPv4, networks will need to be > restructured to free the first /32 , but main problem with it is that > there is no reliable place for additional two bytes for the source > address and additional two bytes for the destination address, that the > ip packets will always pass - with the changes that were made to them > - in each and every router in the world that wasn't upgraded) > > Regarding: > "Proposal by Elad would require hardware level changes on all routers > everywhere before being of any use, so sadly i think it will not get > any traction." > > This is not correct - hardware level changes will not be needed on any > router, only a software update (which is a firmware upgrade) and not > on every router in the world - only in bgp routers and in any non-bgp > routers which have more than two physical routers (NAT routers that > will use an external IPv4+ address and not an IPv4 will also need to > be upgraded, any router in the routing path which is using filtering > based on the source or destination addresses - will also need to have > a firmware upgrade), any homerouter or home modem will not need to be > updated (these are the vast majority of networking equipment in the > world). > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* members-discuss on behalf > of Aleksi > *Sent:* Sunday, April 26, 2020 12:25 AM > *To:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] Technical solution to resolve the > IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 > addresses that are needed in the world > > Hi, > > > ?This is interesting, but it would also possible to add more > "extensions" -- only end side nodes needs to be upgraded on software > level only, client which sends the data, and the regular IPv4 address > receiver. No need for backbone level *hardware* upgrades for this. > > Extend with 2 additional ie. > [0-255].[0-255].[0-255].[0-255].[0-255].[0-255] > Would be the new maximum on base software. > > Example: > Server is 11.11.11.1 > Client is 11.11.12.1.1.1 > Router at 11.11.12.1 > > Server (11.11.11.1) sends packet with additional header data (there is > space for this!) with 2 additional bytes for the extension address. > Router at 11.11.12.1 gets this packet, looks inside the header and > notices the 2 additional bytes and forwards this to client at LOCAL > 11.11.12.1.1.1 (L2 lookup) > > Intermediate switches between router and client do not need to > understand this, only end to end, and the router (which could be > software driven so 1st step only a linux kernel module!) > > > BGP or routing does not need changes, as no routes of extended > addresses are being announced nor allowed to be announced. Therefore > each final /32 can be extended by equivalent of /16 with very minimal > work -- initially only software upgrades on each side. > > > For years i've been wondering why no one has proposed this, so simple > and elegant with minimal hardware investment. *none* of the bloat on > IPv6, just a very simple extension. No performance drawbacks on > routing level, only "end points" need to support it. > > > Then again, i would wish also maximum packet size to be increased by > order of magnitude(s). > > Proposal by Elad would require hardware level changes on all routers > everywhere before being of any use, so sadly i think it will not get > any traction. > > My proposal is unlikely to get any traction either, as it's not to the > benefit of big players (who currently holds vast quantities of unused > IPv4 address space). I just keep wondering why no one would come up > with such a simple idea. This could be done at higher than L3 even -- > but atleast initially would be essentially "L3.5" somewhere between L3 > and L4... > > > > -Aleksi > Magna Capax Finland > > > On 4/25/20 9:20 PM, Elad Cohen wrote: >> Hello Everyone, >> >> I want to share with you my technical solution to the "IPv4 >> Exhaustion" problem (without to upgrade each and every router that >> exist in the internet), using the below implementation there will be >> more 4,294,967,296? IPv4 addresses that the world needs so much: >> >> Currently in an IPv4 packet - the source address and the destination >> address are being represented each by four bytes, each of these four >> bytes are being displayed as: [0-255].[0-255].[0-255].[0-255] >> >> But it is up to us to choose how we want to display them, for >> example: four bytes can also be displayed as [0-65535].[0-65535] (two >> numbers and one dot, the two numbers are bigger because in total they >> also being represented as four bytes) >> >> So there can be one set of 4,294,967,296? IPv4 addresses (the one >> that we know in the display format of [0-255].[0-255].[0-255].[0-255]) >> >> and another set of 4,294,967,296 IPv4 addresses (with a new format of >> [0-65535].[0-65535]) >> >> We need to have a mark, a flag, in the ip packet header - in order to >> know if the source address is of the old formatting (IPv4) or of the >> new formatting (lets call it IPv4+), for that mark the 'reserved bit' >> in the ip header can be used, so in case the source address is of >> IPv4+ or in case that the destination address is of IPv4+ (or in case >> that both the source and destination addresses are of IPv4+) then the >> reserved bit in the ip header will be set to 1 , we then also need to >> know exactly if the source address is of IPv4+ or not (meaning of >> IPv4) and if the destination address is of IPv4+ or not (meaning of >> IPv4) - this can be done by marking the DF flag if the source address >> is of IPv4+ (and not marking the DF flag if the source address is of >> IPv4) and marking the MF flag if the destination address is of IPv4+ >> (and not marking the MF flag if the destination address is of IPv4), >> by using the DF and MF bits which are related to fragmentation >> (whenever the reserved bit is set to '1') we are losing the ip >> fragmentation functionality for any traffic with an IPv4+ address >> (for traffic between two IPv4 addresses, the reserved bit is not set >> to '1' and hence optional ip fragment functionality is unchanged) >> >> We need to know the MTU before an IPv4+ packet will be sent, because >> no fragmentation will be able to be done with IPv4+ , the current >> "Path MTU Discovery" (RFC 1191) is not good for that case because it >> is using the DF bit which we are using as well (and in IPv4+ traffic >> a DF flag set to 1 is marking that the source address is of IPv4+), >> and also ICMP protocol can be blocked by routers in the routing path, >> the solution is to send multiple udp requests (with fixed known MTU >> sizes) to the destination address (lets call it IPv4+ handshake) - >> the destination address may or may not receive them (in case a router >> in the routing path have multiple upstreams and wasn't upgraded to an >> upper version that supports IPv4+ then it will not recognize the >> reserved bit and the DF and MF bits related to it, it will not >> recognize the new IPv4+ addresses and even if the reserved bit is set >> to '1' and MF flag is set to '1' in the ip packet - it will route to >> to the destination address just like it is an IPv4 address and not >> IPv4+ address, meaning to a completely different destination address) >> - in case the destination address indeed received the IPv4+ packets - >> it will send back the udp requests to the source address at the exact >> same sizes (with the reserved bit flag set to '1' and with the DF and >> MF flags set accordingly) - when the source address will receive them >> - the source address will know that the destination address is >> supporting IPv4+ , that ip packets with new IPv4+ formatting will >> reach the destination and the source address will know what is the >> biggest size of the udp request that was received - and it will be >> the MTU for that specific connection between the source and the >> destination addresses (The IPv4+ handshake will be done again if >> there is no response from the destination after the initial udp >> handshake was already completed successfully). >> >> The udp handshake between a source address and a destination address >> (that any of them or them both is an IPv4+ address) will use a >> specific udp port, an availalbe unassigned port between 0 to 1023, an >> operating system networking stack (that was updated for IPv4+ with >> the operating system automatic updating system) will know exactly >> what this udp port is for - and will react accordingly, the upgraded >> operating system networking stack will also check that the >> destination address (in the IPv4 or in the IPv4+ format) is set >> locally in the operating system, before sending the udp requests back >> to the source address (if not then the ip packet will be dropped by >> the upgraded operating system networking stack). Any operating system >> that wasn't upgraded to support IPv4+ - will just drop that kind of >> udp requests. >> >> IPv4+ is fully backward compatible to IPv4 (and any router that was >> not upgraded yet to IPv4+ will not cause IPv4 traffic to break), it >> is also not adding any new fields to ip packets or using new fields, >> IPv4+ will not cause any performance overload for any supported router. >> >> The reason that the MF and DF bits are being use for IPv4+ and not >> the ToS / IP-ID / Options in ip header are being used is because we >> cannot be 100% sure that the ToS / IP-ID / Options in the ip header >> will not be changed or dropped by any rouer in the routing path that >> wasn't upgraded to IPv4+ (and we don't want to upgrade any router in >> the world because it is an impossible mission) - in the ip header ToS >> is being cleared by some routers - IP-ID can be changed by NAT >> routers - Options field is dropped by many routers, we can trust that >> the DF and MF flags will not be modified in the routing path by >> routers that weren't upgraded to IPv4+. >> >> For the above solution not all the internet devices in the world >> needs to be patched/upgraded to support IPv4+ which is an impossible >> mission, end-users operating systems need to be upgraded (but it can >> be done simply using their automatic updating system), BGP routers >> (and any router with multiple physical routing paths) will need to >> have its firmware upgraded to support IPv4+, any NAT router that will >> want to use an external IPv4+ address will need to have its firmware >> upgraded (any NAT router that will use an external IPv4 address will >> not need to have its firmware upgraded, only the internet devices in >> the LAN of the NAT router will need to have a single operating system >> update in order for them to access IPv4+ addresses in the internet), >> any home router (not NAT) or home modem will not need to have a >> firmware upgrade and IPv4+ functionality will be transparent to them. >> >> The deployment of IPv4+ can be fairly easy and very fast, a round >> table of one person from each one of the 5 RIRs and from each one of >> the operating systems vendors and from each one of the router >> manufacture vendors. Even if IPv4+ will be deployed over time, it >> will not cause the internet to break (devices that need to be >> upgraded to IPv4+ and didn't yet will work exactly as they are now >> with IPv4, they will just not yet support IPv4+). >> >> The above will resolve the "IPv4 Exhaustion" problem and will bring >> to each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that >> will be able to the provided to the LIRs worldwide, if you have any >> question please let me know. >> >> Respectfully, >> Elad >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi -------------- next part -------------- An HTML attachment was scrubbed... URL: From juergen.jaritsch at jmpts.ch Sun Apr 26 13:07:32 2020 From: juergen.jaritsch at jmpts.ch (=?iso-8859-1?Q?J=FCrgen_Jaritsch_=28juergen=2Ejaritsch=40jmpts=2Ech=29?=) Date: Sun, 26 Apr 2020 11:07:32 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , <678a5821-de4d-a75d-d74f-5af21c07fe11@lenfiber.it> Message-ID: <143d4ae2f3f1410280104e719eb4aac7@aaa-exchg01.aaa-sales.local> Dear Elad, do you know what a ASIC is? Do you know how non-software defined registers work? Let's make it very easy for everyone: Do you ever thought about thinks like firewalls/loadbalancers and their GUIs? About software, that verifies IP-addresses by regex? Your idea is not compatible with existing software. Please share some detailed examples how to bypass such issues. EVEN if the hardware of the (e.g.) firewalls is able to handle the "new" IP addresses of IPv4+: the GUI have to be fixed/updated - on EVERY firewall around the world. Otherwise you'll never have any end-to-end IPv4+ connection. Same counts for software like Webservers (e.g. Apache virtual hosts can refer to IPs in the config), IPTables, databases systems, etc etc. All this software depends on existing network stack but also have configuration verification/testing processes which will not work with (unexpected) IPv4+ addresses in the configuration. What about DHCP, DNS, BGP, Peering fabrics (AMSIX,DECIC, etc) etc? This have to be adapted too. Regarding your "switches are L2 only" statement: did you ever heard about MPLS- and/or L3-switches? They could be EOL/EOS but have full support for IPv4/IPv6 so there is no real statement against using them in existing (closed/company) networks (beside the case of defective hardware). Users of this device will not receive updates from the vendors. What about big vendors? You said it's "easy" and "cheap" to implement: what if hardware line cards like Juniper MPC does not support this? This cards are used in many backbone routers. Should the carriers simple replace them? To be honest: from a theoretical point of view your idea sounds great, but you have to consider way more details / functions / devices / situations /implementations. Your idea is nothing simple to "activate" like an feature. You can't tell a carrier "if your Juniper MPC does not support IPv4+, you have to use NAT" - seriously? With hundreds if Gbps? Best regards J?rgen Von: members-discuss Im Auftrag von Elad Cohen Gesendet: Sonntag, 26. April 2020 12:38 An: Thomas Gallo @ Lenfiber S.p.A. ; members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ASICs or any device with a similar problem, can be connected to the internet through a NAT router, the NAT router will help the ASIC or the similar device with IPv4+ (The ASIC or the similar device will only be able to initiate connections to IPv4, but any ip addresses in the internet - IPv4 or IPv4+ will be able to initiate a connection to the ASIC or the similar device and then to create a session with it, the NAT router will monitor the session and will set the IPv4+ bits accordingly) In advanced configuration in the NAT router there can be an option that all ip packets that will originate from the specific ASIC will be only to IPv4+ addresses (and not to IPv4) so the NAT router will always set the IPv4+ related bits in any ip packet originated from the ASIC or similar device. Respectfully, Elad ________________________________________ From: members-discuss on behalf of Thomas Gallo @ Lenfiber S.p.A. Sent: Sunday, April 26, 2020 1:03 PM To: mailto:members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ? Hi, many years ago it could have been a good idea.. but even if all of this could be implemented on the software side today... but what about ASICs and so forth? (thinking to circuitry that do lookup based on 32bits for example) Best regards, Thomas Il 26/04/2020 11:52, Elad Cohen ha scritto: Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; mailto:members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws,? can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home. * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections _______________________________________________ members-discuss mailing list mailto:members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/thomas.gallo%40lenfiber.it -- Thomas Gallo email: mailto:thomas.gallo at lenfiber.it Amministratore unico Lenfiber S.p.A. Centro Direzionale Interporto Padova - Torre B Galleria Spagna, 36 - 35127 Padova (PD) ph: +39 049 85 94 766 fax: +39 049 82 51 032 P.Iva/VAT: IT04669150288 Cap.Soc. 200.000,00 Euro i.v. http://www.lenfiber.it From christian.meutes at pwc.com Sun Apr 26 13:08:52 2020 From: christian.meutes at pwc.com (Christian Meutes (DE)) Date: Sun, 26 Apr 2020 13:08:52 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: Hello Elad, let me be straight: your "solution" makes so many naive assumptions, technically and economically, while leaving out a hell of requirements and conditions of real world networks and IP stacks, that I'm totally torn between either interpreting your mail as a joke or just as a well-meant but clueless attempt to solve the problem of scaling the most important communication protocol on this planet to another version of it. Seriously, do you really believe that by stealing some bits from the IPv4 header here and there and using UDP for *path* MTU discovery you have found the solution to our addressing problems right now? The amount of considerations to make in an attempt to change something of this kind of size is so huge and the way to make it a success so dynamic and hard to predict that it will take years of hard work until you might get working code from vendors and real world support by Internet operators and major host stacks. You are basically suggesting two technical things to make the current IPv4 address-space larger while being non-disruptive to the current IPv4 standard and claiming it an alternative which could be deployed faster and easier than IPv6: a) 33-bit addressing, the new half in a new address-family, lookup on the IP header Flags field to decide how to interpret SADDR and DADDR fields 1. Not only will that involve a lot of engineering in routing-protocols and their dependencies, but will just not work for many of them w/o a complete new standard for them as well 2. IP stacks not supporting this extension will *wrongly* interpret the packet having normal IPv4 addresses. This creates a HELL OF ISSUES, from bypassing ACLs to routing-loops and DoS, to forged end-to-end connectivity. 3. Most IPv4 h/w implementations will not be able to use another round of lookup on Flags field to choose the proper forwarding table. Certainly this can be done, but it will take years until we would see it being shipped. b) UDP-based path MTU discovery up front, needs to succeed before any IPv4+ socket should be able to transmit packets 1. If you are only able to communicate with another IPv4+ host by testing for UDP connectivity then good luck in real world networks. IPv4+ will never work if this is a requirement to get any socket up. 2. If the path in between converges in some way thus making your packets crossing a router suddenly not supporting IPv4+ then this will lead to all kinds of weird and problematic behavior. This is a HUGE security flaw. From intercepting and eavesdropping to suddenly DoSing some IPv4 host with a 100Gbps IPv4+ stream. There are dozens of other concerns and problems with your "solution", but seriously I don't believe we should discuss that here for *you*. It's really the wrong mailing-list for that and your "draft" has not even reached omega status for making it discussable with such a wide audience of Internet operators. Thanks On Sat, 25 Apr 2020 at 20:36, Elad Cohen wrote: > I want to share with you my technical solution to the "IPv4 Exhaustion" > problem (without to upgrade each and every router that exist in the > internet), using the below implementation there will be more 4,294,967,296? > IPv4 addresses that the world needs so much: > > Currently in an IPv4 packet - the source address and the destination > address are being represented each by four bytes, each of these four bytes > are being displayed as: [0-255].[0-255].[0-255].[0-255] > > But it is up to us to choose how we want to display them, for example: > four bytes can also be displayed as [0-65535].[0-65535] (two numbers and > one dot, the two numbers are bigger because in total they also being > represented as four bytes) > > So there can be one set of 4,294,967,296? IPv4 addresses (the one that we > know in the display format of [0-255].[0-255].[0-255].[0-255]) > > and another set of 4,294,967,296 IPv4 addresses (with a new format of > [0-65535].[0-65535]) > > We need to have a mark, a flag, in the ip packet header - in order to know > if the source address is of the old formatting (IPv4) or of the new > formatting (lets call it IPv4+), for that mark the 'reserved bit' in the ip > header can be used, so in case the source address is of IPv4+ or in case > that the destination address is of IPv4+ (or in case that both the source > and destination addresses are of IPv4+) then the reserved bit in the ip > header will be set to 1 , we then also need to know exactly if the source > address is of IPv4+ or not (meaning of IPv4) and if the destination address > is of IPv4+ or not (meaning of IPv4) - this can be done by marking the DF > flag if the source address is of IPv4+ (and not marking the DF flag if the > source address is of IPv4) and marking the MF flag if the destination > address is of IPv4+ (and not marking the MF flag if the destination address > is of IPv4), by using the DF and MF bits which are related to fragmentation > (whenever the reserved bit is set to '1') we are losing the ip > fragmentation functionality for any traffic with an IPv4+ address (for > traffic between two IPv4 addresses, the reserved bit is not set to '1' and > hence optional ip fragment functionality is unchanged) > > We need to know the MTU before an IPv4+ packet will be sent, because no > fragmentation will be able to be done with IPv4+ , the current "Path MTU > Discovery" (RFC 1191) is not good for that case because it is using the DF > bit which we are using as well (and in IPv4+ traffic a DF flag set to 1 is > marking that the source address is of IPv4+), and also ICMP protocol can be > blocked by routers in the routing path, the solution is to send multiple > udp requests (with fixed known MTU sizes) to the destination address (lets > call it IPv4+ handshake) - the destination address may or may not receive > them (in case a router in the routing path have multiple upstreams and > wasn't upgraded to an upper version that supports IPv4+ then it will not > recognize the reserved bit and the DF and MF bits related to it, it will > not recognize the new IPv4+ addresses and even if the reserved bit is set > to '1' and MF flag is set to '1' in the ip packet - it will route to to the > destination address just like it is an IPv4 address and not IPv4+ address, > meaning to a completely different destination address) - in case the > destination address indeed received the IPv4+ packets - it will send back > the udp requests to the source address at the exact same sizes (with the > reserved bit flag set to '1' and with the DF and MF flags set accordingly) > - when the source address will receive them - the source address will know > that the destination address is supporting IPv4+ , that ip packets with new > IPv4+ formatting will reach the destination and the source address will > know what is the biggest size of the udp request that was received - and it > will be the MTU for that specific connection between the source and the > destination addresses (The IPv4+ handshake will be done again if there is > no response from the destination after the initial udp handshake was > already completed successfully). > > The udp handshake between a source address and a destination address (that > any of them or them both is an IPv4+ address) will use a specific udp port, > an availalbe unassigned port between 0 to 1023, an operating system > networking stack (that was updated for IPv4+ with the operating system > automatic updating system) will know exactly what this udp port is for - > and will react accordingly, the upgraded operating system networking stack > will also check that the destination address (in the IPv4 or in the IPv4+ > format) is set locally in the operating system, before sending the udp > requests back to the source address (if not then the ip packet will be > dropped by the upgraded operating system networking stack). Any operating > system that wasn't upgraded to support IPv4+ - will just drop that kind of > udp requests. > > IPv4+ is fully backward compatible to IPv4 (and any router that was not > upgraded yet to IPv4+ will not cause IPv4 traffic to break), it is also not > adding any new fields to ip packets or using new fields, IPv4+ will not > cause any performance overload for any supported router. > > The reason that the MF and DF bits are being use for IPv4+ and not the ToS > / IP-ID / Options in ip header are being used is because we cannot be 100% > sure that the ToS / IP-ID / Options in the ip header will not be changed or > dropped by any rouer in the routing path that wasn't upgraded to IPv4+ (and > we don't want to upgrade any router in the world because it is an > impossible mission) - in the ip header ToS is being cleared by some routers > - IP-ID can be changed by NAT routers - Options field is dropped by many > routers, we can trust that the DF and MF flags will not be modified in the > routing path by routers that weren't upgraded to IPv4+. > > For the above solution not all the internet devices in the world needs to > be patched/upgraded to support IPv4+ which is an impossible mission, > end-users operating systems need to be upgraded (but it can be done simply > using their automatic updating system), BGP routers (and any router with > multiple physical routing paths) will need to have its firmware upgraded to > support IPv4+, any NAT router that will want to use an external IPv4+ > address will need to have its firmware upgraded (any NAT router that will > use an external IPv4 address will not need to have its firmware upgraded, > only the internet devices in the LAN of the NAT router will need to have a > single operating system update in order for them to access IPv4+ addresses > in the internet), any home router (not NAT) or home modem will not need to > have a firmware upgrade and IPv4+ functionality will be transparent to > them. > > The deployment of IPv4+ can be fairly easy and very fast, a round table of > one person from each one of the 5 RIRs and from each one of the operating > systems vendors and from each one of the router manufacture vendors. Even > if IPv4+ will be deployed over time, it will not cause the internet to > break (devices that need to be upgraded to IPv4+ and didn't yet will work > exactly as they are now with IPv4, they will just not yet support IPv4+). > > The above will resolve the "IPv4 Exhaustion" problem and will bring to > each one of the 5 RIRs almost 900,000,000 new IPv4+ addresses that will be > able to the provided to the LIRs worldwide, if you have any question please > let me know. > > Respectfully, > Elad > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/christian.meutes%40pwc.com > Christian -- Diese Information ist ausschliesslich fuer den Adressaten bestimmt und kann vertrauliche oder gesetzlich geschuetzte Informationen enthalten. Wenn Sie nicht der bestimmungsgemaesse Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemaessen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Wir verwenden aktuelle Virenschutzprogramme. Fuer Schaeden, die dem Empfaenger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schliessen wir jede Haftung aus.?* * * * * The information contained in this email is intended only for its addressee and may contain confidential and/or privileged information. If the reader of this email is not the intended recipient, you are hereby notified that reading, saving, distribution or use of the content of this email in any way is prohibited. If you have received this email in error, please notify the sender and delete the email. We use updated antivirus protection software. We do not accept any responsibility for damages caused anyhow by viruses transmitted via email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 13:11:44 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 11:11:44 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <20200426104228.GL90387@carcass.ledeuns.net> References: , <20200426104228.GL90387@carcass.ledeuns.net> Message-ID: Didn't you read what I wrote regarding the round table ? Each member of the round table will be responsible to update its own software and will be rewarded for it, not you will do it and not your useless friends that can do nothing but sit and let other do their hard work, I did the hard work here, you are the talker. "it shows that you don't have a clue what you are talking about" - protocols are flows, you don't need to implement a protocol in order to prove it works, no one here denied that it will work besides the disturbed IPv6 fanatic that didn't agree to write any flaw publicly in order for me to confront with him, Ripe have a list of expenses of 30 million euros per year, go ask Ripe to assign a very small part of it for the implementation. Do you want me to patch any networking stack of any operating system that exist ? do I have the source code from Microsoft ? Respectfully, Elad ________________________________ From: members-discuss on behalf of Denis Fondras Sent: Sunday, April 26, 2020 1:42 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Claiming it is "easy" to implement is no enough. Please show us a working implementation (a proof of concept), it should not be hard. Or is it hard for you but easy for anyone else to do ? If so, it shows that you don't have a clue what you are talking about. I find that a bit sad. In France, we call people like you "Yakafokon". It means that talk is cheap, you have a supposed solution but will let others deal with the dirty work. You will not convince any of us with words. Roll up their sleeves and show us that it works somewhere else than your own mind (any supporter of your idea can join). The idea of using "unused" fields in the IPv4 header to extend adressing space is not new, it has been discussed multiple times everywhere on the Internet. We have never seen a single working implementation. You can still believe it is because the "IPv6 sect" has been actively undermining the work... For anyone claiming to have a solution for the "IPv4 exhaustion problem", do your homework before wasting the time of hundreds of mailing list participants. Thank you in advance. _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/elad%40netstyle.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From juergen.jaritsch at jmpts.ch Sun Apr 26 13:14:30 2020 From: juergen.jaritsch at jmpts.ch (=?iso-8859-1?Q?J=FCrgen_Jaritsch_=28juergen=2Ejaritsch=40jmpts=2Ech=29?=) Date: Sun, 26 Apr 2020 11:14:30 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> , , <5393a4c1038d40798cc0cf66656f83ef@safehosts.co.uk> , <5fea3db6d3ab4b2bb08af999625b0238@safehosts.co.uk> Message-ID: <440a3c793a794c40bf0ac2dfac80c18b@aaa-exchg01.aaa-sales.local> Dear Elad, > Any home-modem will not need to be updated (no matter if it is L2 or L3). Ok, let's proceed with your idea: what happens to a service that is only reachable by IPv4+? It will only be reachable by native IPv4+ or by an NAT solution, right? Why re-invent the wheel? There is already IPv6 available, why should someone spend time in developing a NAT for IPv4+? What's the benefit? Affected end-users (with IPv4/IPv6 Dual-Stack devices) will never be able to reach a IPv4+ address (if there is no NAT available). This makes it useless. And regarding your UDP "handshake" for MTU: There are MANY networks around the world which breaks UDP and there are also many situations where you filter UDP. What is your idea for such cases? Best regards J?rgen Von: members-discuss Im Auftrag von Elad Cohen Gesendet: Sonntag, 26. April 2020 12:52 An: Stuart Willet (primary) ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Any home-modem will not need to be updated (no matter if it is L2 or L3). Regarding the EOL list you provided, Cisco will be part of the round table (just like any other routing equipment manufacturer) and firmware upgrades will be provided by any round table member even for its EOL products so the deployment of IPv4+ will be possible. Respectfully, Elad ________________________________________ From: Stuart Willet (primary) Sent: Sunday, April 26, 2020 1:48 PM To: Elad Cohen ; Sander Steffann Cc: Gert D?ring ; mailto:members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ? You keep saying "Any home modem will not need to be updated at all" and you keep saying switches are L2. My home modem is a L3 device. There are a lot of L3 switches which have hit end of life in lots of data centres around the world. Regardless of how many times you SAY these are L2 switches, they are not. ? By way of example, here is just a handful of Cisco's EOL Layer 3 (IP based) devices which would need some kind of upgrade or replacement: ? Cisco 6000 Series IP DSL Switches Cisco Blade Switches for Dell Cisco Blade Switches for HP Cisco Catalyst 3750 Series Switches Cisco Catalyst 3750-X Series Switches Cisco Catalyst 3560 Series Switches Cisco Catalyst 3560-C Series Switches Cisco Catalyst 3560-X Series Switches Cisco Catalyst 2960 Series Switches Cisco Catalyst 2960-S Series Switches Cisco Catalyst 2960-SF Series Switches Cisco Catalyst 2955 Series Switches Cisco Catalyst 2360 Series Switches Cisco Energy Management Suite Cisco ME 4600 Series Multiservice Optical Access Platform Cisco ME 3800X Series Carrier Ethernet Switch Routers Cisco ME 3600X Series Ethernet Access Switches Cisco ME 3400E Series Ethernet Access Switches Cisco ME 2600X Series Ethernet Access Switches Cisco Nexus 4000 Series Switches Cisco Nexus 1100 Series Cloud Services Platforms Cisco Small Business 500 Series Stackable Managed Switches Cisco Small Business 100 Series Unmanaged Switches Cisco Switch Modules for IBM Cisco Virtual Application Cloud Segmentation (VACS) Services Citrix NetScaler 1000V ? Remember, this is only Cisco and only a partial list. You will need to add Juniper, HP, Dell, D-Link, Alcatel, Foundry, Marconi, Nortel and many many more. You will also need to update EVERY distro of Linux, Unix, Windows and other more bespoke operating systems. ? Best, Stuart Willet. ? ? ? From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:18 To: Stuart Willet (primary) ; Sander Steffann Cc: Gert D?ring ; mailto:members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ? I already answered to you one minute ago. No software update will need to be done to any modem, I wrote it many many times but you ignored it - so please don't blame it on me. ? Here is again: Any home modem will not need to be updated at all ? Respectfully, Elad ________________________________________ From: Stuart Willet (primary) Sent: Sunday, April 26, 2020 1:16 PM To: Elad Cohen ; Sander Steffann Cc: Gert D?ring ; mailto:members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ? Show me how to "software update" my BT modem to accept iPv4 (rhetorical) ? I'm sorry, but you have had plenty of feedback from lots of people. You refuse to see the obvious, nobody is going to spend the man hours required. ? I am now respectfully bowing out, I have wasted enough time on this. ? Please feel free to tell people I am part of an IPv6 conspiracy against you, but also accept that this is nonsense. ? ? Best regards, ? Stuart Willet. ? From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:07 To: Stuart Willet (primary) ; Sander Steffann Cc: Gert D?ring ; mailto:members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ? But you didn't understand IPv4+ based on what you are writing or you are trying to influence the readers... ? First fully understand something, then decide if you are against it or not. ? Regarding: "you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresse" ? No hardware upgrades will be need, only software updates and the software developers (operating system vendors and routing equipment manufacturers) will receive incentives. End-users / companies / organizations - will need to invest nothing. ? Respectfully, Elad ? ________________________________________ From: Stuart Willet (primary) Sent: Sunday, April 26, 2020 1:03 PM To: Elad Cohen ; Sander Steffann Cc: Gert D?ring ; mailto:members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ? You have not convinced me, I make no money from IPv6. I have no incentive to push IPv6 or downplay IPv4 or IPV4+ ? Your idea is flawed and that's that. ? ? Sorry, ? Stuart Willet. ? From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:00 To: Stuart Willet (primary) ; Sander Steffann Cc: Gert D?ring ; mailto:members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ? Stuart, ? The people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. ? Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. ? Respectfully, Elad ? ________________________________________ From: Stuart Willet (primary) Sent: Sunday, April 26, 2020 12:54 PM To: Elad Cohen ; Sander Steffann Cc: Gert D?ring ; mailto:members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ? Elad, ? You are now making yourself look a little paranoid and silly. ? ? Respectfully, ? Stuart Willet. ? From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:53 To: Sander Steffann Cc: Gert D?ring ; mailto:members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ? Sander is taking part in an illegal cyber influence operation against me. ? Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. ? Respectfully, Elad ? ? ________________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; mailto:members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ? Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws,? can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home. * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections From laurent.seror at outscale.com Sun Apr 26 13:11:20 2020 From: laurent.seror at outscale.com (Laurent Seror) Date: Sun, 26 Apr 2020 13:11:20 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <5CA599DF-725A-4665-9422-30E7E2979551@fiberdirekt.se> References: <20200426090930.GN50230@Space.Net> <5CA599DF-725A-4665-9422-30E7E2979551@fiberdirekt.se> Message-ID: Hi all, Here is my two cents. I think we should follow the RFC process. Write down all the engineral proposal, request for comments, rewrite accordingly, rinse and repeat, when it's mature discuss it with IETF, got an official RFC number and help people who want to implement it. There will always be people for are for or against, it's pointless to try to convince everyone. All ideas have value, some more than others. L. Le dim. 26 avr. 2020 ? 13:02, Peter Linder a ?crit : > Elad, > > You must know that all routing on the isp level is done in dedicated > hardware with specifically made chips. These routers will all need new line > cards at the minimum. > > Elad Cohen skrev: (26 april 2020 12:05:45 CEST) >> >> But you didn't understand IPv4+ based on what you are writing or you are >> trying to influence the readers... >> >> First fully understand something, then decide if you are against it or >> not. >> >> Regarding: >> "you want millions of dollars spent on millions of upgrades for a >> handful of new IPv4 addresse" >> >> No hardware upgrades will be need, only software updates and the software >> developers (operating system vendors and routing equipment manufacturers) >> will receive incentives. End-users / companies / organizations - will need >> to invest nothing. >> >> Respectfully, >> Elad >> ------------------------------ >> *From:* Stuart Willet (primary) >> *Sent:* Sunday, April 26, 2020 1:02 PM >> *To:* Elad Cohen ; Sander Steffann ; >> Gert D?ring >> *Cc:* members-discuss at ripe.net >> *Subject:* RE: [members-discuss] Technical solution to resolve the IPv4 >> Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are >> needed in the world >> >> >> Elad, >> >> >> >> I am against your idea, you have not won me over and I don?t think you >> are likely to. >> >> I have repeatedly said this will not work. >> >> >> >> It?s a nice idea, and would have had promise if it was introduced before >> IPv6 but as things stand today, you want millions of dollars spent on >> millions of upgrades for a handful of new IPv4 addresses. >> >> >> >> As I said, if you are having this much trouble introducing it to us, you >> don?t stand a chance. >> >> >> >> >> >> Best, >> >> >> >> Stuart Willet. >> >> >> >> *From:* Elad Cohen [mailto:elad at netstyle.io] >> *Sent:* 26 April 2020 10:59 >> *To:* Stuart Willet (primary) ; Sander Steffann < >> sander at steffann.nl>; Gert D?ring >> *Cc:* members-discuss at ripe.net >> *Subject:* Re: [members-discuss] Technical solution to resolve the IPv4 >> Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are >> needed in the world >> >> >> >> Stuart, >> >> >> >> I don't have any trouble convincing you, the people that responded are >> not reflecting the opinion of the vast majority of internet companies and >> internet organizations - which needs IPv4. >> >> >> >> Each and every person that I wasn't able to convince as you wrote is an >> active deployer of IPv6 and earns his money from deploying IPv6. >> >> >> >> Respectfully, >> >> Elad >> ------------------------------ >> >> *From:* Stuart Willet (primary) >> *Sent:* Sunday, April 26, 2020 12:46 PM >> *To:* Elad Cohen ; Sander Steffann ; >> Gert D?ring >> *Cc:* members-discuss at ripe.net >> *Subject:* RE: [members-discuss] Technical solution to resolve the IPv4 >> Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are >> needed in the world >> >> >> >> Respectfully Elad, you are pushing your idea without considering the >> consequences. >> >> There is no operation against you, we are just trying to point out the >> flaws in your idea. >> >> Just consider this, you are currently speaking with the group that will >> inevitably be the ones to roll out your idea. If you are having this much >> trouble convincing us this is a good idea, how would the rest of the world >> hold up? >> >> >> >> You keep saying this will work with existing IPv4 but it simply won?t >> will it. >> >> I have a home internet connection provided by BT. They give me an IPv4 >> and an IPv6 address. >> >> Traffic preferences IPv6 where it can. >> >> >> >> How would IPv4+ be added in this scenario? Simple, a firmware update >> would need to be made on my router. And every router for every other BT >> customer. >> Same will apply for VirginMedia et-al. >> >> You keep saying it won?t be needed unless there is NAT, but most home >> routers use NAT. >> >> Please explain to me how you think Microsoft are going to spend millions >> on your upgrade for zero benefit to them? >> Please explain how ISP?s will recall and replace millions of set top >> boxes and modems? >> Please explain how upgrades are going to be done on end of life switches >> and routers? >> >> Please explain how every DNS server on the planet will be upgraded >> seamlessly? >> >> >> >> Seriously, if you are having this hard a time winning us over, you don?t >> stand a chance. >> >> >> >> Best, >> >> >> >> Stuart Willet. >> >> >> >> *From:* members-discuss [mailto:members-discuss-bounces at ripe.net >> ] *On Behalf Of *Elad Cohen >> *Sent:* 26 April 2020 10:37 >> *To:* Sander Steffann ; Gert D?ring >> *Cc:* members-discuss at ripe.net >> *Subject:* Re: [members-discuss] Technical solution to resolve the IPv4 >> Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are >> needed in the world >> >> >> >> Hello Everyone, >> >> >> >> What being done here is a cyber influence operation against me, after I'm >> only trying to do good to the community. >> >> >> >> Sander, you didn't mention any flaws, can you please write them here and >> I will answer each and every one of them ? >> >> >> >> First there was the IPv6 fans and now there are the Spamhaus fans. >> >> >> >> Respectfully, >> >> Elad >> ------------------------------ >> >> *From:* members-discuss on behalf of >> Sander Steffann >> *Sent:* Sunday, April 26, 2020 12:28 PM >> *To:* Gert D?ring >> *Cc:* members-discuss at ripe.net >> *Subject:* Re: [members-discuss] Technical solution to resolve the IPv4 >> Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are >> needed in the world >> >> >> >> Hi, >> >> > On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: >> >> I think it is appropriate to close this discussion here. >> >> Elad will eventually submit his proposed al RIPE meeting or he'll >> write a >> >> RFC. >> > >> > Basically, this. >> >> Seconded >> >> > [...] >> > >> > Overall, as long as no implementations can be provided (source code on >> > github etc) this sounds like a somewhat cheap shot to make people >> believe >> > you're going to solve their IPv4 problems if they just vote you to the >> > NCC executive board. And I hope the NCC members are smart enough to not >> > vote based on glorious promises, but on track record, provable >> background, >> > etc. >> >> I have contacted Elad off-list and shown him many fallacies in his >> design. He insisted implementation and deployment of IPv4+ was easy. I told >> him he is delusional and that I emailed him off-list as not to shame him >> publicly, and all he said was: >> >> > Go ahead, shame me publicly and you will receive the exact same >> answers, you are obviously have interests regarding IPv6 and you are trying >> to avoid from the world more IPv4 addresses just for your own personal >> profit. >> > >> > You are obviously have illegal interests in Ripe and this is the only >> reasons for your emails to me. >> >> There is no talking sense into this person. He is oblivious to how the >> internet works and how hardware and software upgrades are implemented and >> deployed. Obviously pointing out his flaws means I have an illegal interest >> somehow. >> >> I think Elad has already tried following Trump's recent advice and we are >> seeing the consequences? >> >> Time to move on? >> Sander >> > > -- > Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/laurent.seror%40outscale.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 13:19:48 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 11:19:48 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <66e746fe7a2347aa949052fab698da45@safehosts.co.uk> References: , <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> , , <5393a4c1038d40798cc0cf66656f83ef@safehosts.co.uk> , <5fea3db6d3ab4b2bb08af999625b0238@safehosts.co.uk> , <66e746fe7a2347aa949052fab698da45@safehosts.co.uk> Message-ID: Cisco as part of the round table, will receive high amount of IPv4+ addresses, they are equally worth to money. You wrote millions of dollars 100,000,000 new IPv4 addresses (from IPv4+) that will be provided to everyone involved including ASN's and ISP's and Operating System vendors and netowrking equipment manufacturers - are worth in total 2 Billion USD , this is much more than the few millions dollars that you wrote. " If providers have not implemented IPv6 on EOL devices, why on earth would they implement IPv4+?" - because I believe that there will be pressure from the community and it will be benefited to them. Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Sunday, April 26, 2020 1:56 PM To: Elad Cohen ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You STILL don?t see the issue? Who is going to pay for all the development? How will Cisco provide updates for EOL kit? This is ONLY a partial list of Cisco kit. There will be thousands of devices from different suppliers which are EOL and will need someone to work out how to update them. This would cost millions of dollars to do worldwide, it just isn?t practical. If providers have not implemented IPv6 on EOL devices, why on earth would they implement IPv4+? EOL = End Of Life, unsupported. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:52 To: Stuart Willet (primary) ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Any home-modem will not need to be updated (no matter if it is L2 or L3). Regarding the EOL list you provided, Cisco will be part of the round table (just like any other routing equipment manufacturer) and firmware upgrades will be provided by any round table member even for its EOL products so the deployment of IPv4+ will be possible. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:48 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You keep saying ?Any home modem will not need to be updated at all? and you keep saying switches are L2. My home modem is a L3 device. There are a lot of L3 switches which have hit end of life in lots of data centres around the world. Regardless of how many times you SAY these are L2 switches, they are not. By way of example, here is just a handful of Cisco?s EOL Layer 3 (IP based) devices which would need some kind of upgrade or replacement: Cisco 6000 Series IP DSL Switches Cisco Blade Switches for Dell Cisco Blade Switches for HP Cisco Catalyst 3750 Series Switches Cisco Catalyst 3750-X Series Switches Cisco Catalyst 3560 Series Switches Cisco Catalyst 3560-C Series Switches Cisco Catalyst 3560-X Series Switches Cisco Catalyst 2960 Series Switches Cisco Catalyst 2960-S Series Switches Cisco Catalyst 2960-SF Series Switches Cisco Catalyst 2955 Series Switches Cisco Catalyst 2360 Series Switches Cisco Energy Management Suite Cisco ME 4600 Series Multiservice Optical Access Platform Cisco ME 3800X Series Carrier Ethernet Switch Routers Cisco ME 3600X Series Ethernet Access Switches Cisco ME 3400E Series Ethernet Access Switches Cisco ME 2600X Series Ethernet Access Switches Cisco Nexus 4000 Series Switches Cisco Nexus 1100 Series Cloud Services Platforms Cisco Small Business 500 Series Stackable Managed Switches Cisco Small Business 100 Series Unmanaged Switches Cisco Switch Modules for IBM Cisco Virtual Application Cloud Segmentation (VACS) Services Citrix NetScaler 1000V Remember, this is only Cisco and only a partial list. You will need to add Juniper, HP, Dell, D-Link, Alcatel, Foundry, Marconi, Nortel and many many more. You will also need to update EVERY distro of Linux, Unix, Windows and other more bespoke operating systems. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:18 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world I already answered to you one minute ago. No software update will need to be done to any modem, I wrote it many many times but you ignored it - so please don't blame it on me. Here is again: Any home modem will not need to be updated at all Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:16 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Show me how to ?software update? my BT modem to accept iPv4 (rhetorical) I?m sorry, but you have had plenty of feedback from lots of people. You refuse to see the obvious, nobody is going to spend the man hours required. I am now respectfully bowing out, I have wasted enough time on this. Please feel free to tell people I am part of an IPv6 conspiracy against you, but also accept that this is nonsense. Best regards, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:07 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world But you didn't understand IPv4+ based on what you are writing or you are trying to influence the readers... First fully understand something, then decide if you are against it or not. Regarding: "you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresse" No hardware upgrades will be need, only software updates and the software developers (operating system vendors and routing equipment manufacturers) will receive incentives. End-users / companies / organizations - will need to invest nothing. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:03 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You have not convinced me, I make no money from IPv6. I have no incentive to push IPv6 or downplay IPv4 or IPV4+ Your idea is flawed and that?s that. Sorry, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:00 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, The people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:54 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, You are now making yourself look a little paranoid and silly. Respectfully, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:53 To: Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home? * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias at brumm.net Sun Apr 26 13:24:23 2020 From: matthias at brumm.net (Matthias Brumm) Date: Sun, 26 Apr 2020 13:24:23 +0200 Subject: [members-discuss] **SPAM** Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426090930.GN50230@Space.Net> Message-ID: <4a02bc8a-9279-a7e2-8b07-46d6ad9a4bcd@brumm.net> Hi! I am working for a small ISP in Germany with providing internet to businesses, operating datacenters and FTTH/FTTC. You have not won me over either. I have the following remarks to your proposal: - You say, that there is simply the reserved bit has to be switched to "1". Simply changing a value which has ever been "0" could and will break things on unclean implementations of the IPv4 protocol. So even if devices should not need updates, they could see some unexpected header-value in there IPv4+ packets just flowing through. - You are stressing automatic updates of the OSs in the world. In a perfect world you may have the posibility to get updates and patches fast to the end-users. But this is not. You have old computer/versions or simply companies and peoiple, who are not updating there software regualarily (i.e. to not break things / test updates thoeoughly) - You are relying on the power of the end user, if they are unable to reach a site. This is the problem with v6 at the moment also. The content providers are not going to be in danger, that their customers are unable to reach their site. If that would be the case, Google or Facebook could just switch of there IPv4 connectivity and only be reachable via v6. But there is money involved. You have requested comments on your idea and you have got them. I would be interessted in your benefit from such an implementation? You will not get new IPv4(+)-addresses within the next two months. As already stated, the RIPE can not implement this. Why are you unable to be happy with IPv6? Where are your problems? We have redesigned our network 4 years ago and we have no problems with IPv6. Matthias Am 26.04.20 um 11:58 schrieb Elad Cohen: > Stuart, > > I don't have any trouble convincing you, the people that responded are > not reflecting the opinion of the vast majority of internet companies > and internet organizations - which needs IPv4. > > Each and every person that I wasn't able to convince as you wrote is > an active deployer of IPv6 and earns his money from deploying IPv6. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* Stuart Willet (primary) > *Sent:* Sunday, April 26, 2020 12:46 PM > *To:* Elad Cohen ; Sander Steffann > ; Gert D?ring > *Cc:* members-discuss at ripe.net > *Subject:* RE: [members-discuss] Technical solution to resolve the > IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 > addresses that are needed in the world > > Respectfully Elad, you are pushing your idea without considering the > consequences. > > There is no operation against you, we are just trying to point out the > flaws in your idea. > > Just consider this, you are currently speaking with the group that > will inevitably be the ones to roll out your idea. If you are having > this much trouble convincing us this is a good idea, how would the > rest of the world hold up? > > You keep saying this will work with existing IPv4 but it simply won?t > will it. > > I have a home internet connection provided by BT. They give me an IPv4 > and an IPv6 address. > > Traffic preferences IPv6 where it can. > > How would IPv4+ be added in this scenario? Simple, a firmware update > would need to be made on my router. And every router for every other > BT customer. > Same will apply for VirginMedia et-al. > > You keep saying it won?t be needed unless there is NAT, but most home > routers use NAT. > > Please explain to me how you think Microsoft are going to spend > millions on your upgrade for zero benefit to them? > Please explain how ISP?s will recall and replace millions of set top > boxes and modems? > Please explain how upgrades are going to be done on end of life > switches and routers? > > Please explain how every DNS server on the planet will be upgraded > seamlessly? > > Seriously, if you are having this hard a time winning us over, you > don?t stand a chance. > > Best, > > Stuart Willet. > > *From:*members-discuss [mailto:members-discuss-bounces at ripe.net] *On > Behalf Of *Elad Cohen > *Sent:* 26 April 2020 10:37 > *To:* Sander Steffann ; Gert D?ring > *Cc:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] Technical solution to resolve the > IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 > addresses that are needed in the world > > Hello Everyone, > > What being done here is a cyber influence operation against me, after > I'm only trying to do good to the community. > > Sander, you didn't mention any flaws,? can you please write them here > and I will answer each and every one of them ? > > First there was the IPv6 fans and now there are the Spamhaus fans. > > Respectfully, > > Elad > > ------------------------------------------------------------------------ > > *From:*members-discuss > on behalf of Sander > Steffann > > *Sent:* Sunday, April 26, 2020 12:28 PM > *To:* Gert D?ring > > *Cc:* members-discuss at ripe.net > > > *Subject:* Re: [members-discuss] Technical solution to resolve the > IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 > addresses that are needed in the world > > Hi, > > > On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: > >> I think it is appropriate to close this discussion here. > >> Elad will eventually submit his proposed al RIPE meeting or he'll > write a > >> RFC. > > > > Basically, this. > > Seconded > > > [...] > > > > Overall, as long as no implementations can be provided (source code on > > github etc) this sounds like a somewhat cheap shot to make people > believe > > you're going to solve their IPv4 problems if they just vote you to the > > NCC executive board.? And I hope the NCC members are smart enough to not > > vote based on glorious promises, but on track record, provable > background, > > etc. > > I have contacted Elad off-list and shown him many fallacies in his > design. He insisted implementation and deployment of IPv4+ was easy. I > told him he is delusional and that I emailed him off-list as not to > shame him publicly, and all he said was: > > > Go ahead, shame me publicly and you will receive the exact same > answers, you are obviously have interests regarding IPv6 and you are > trying to avoid from the world more IPv4 addresses just for your own > personal profit. > > > > You are obviously have illegal interests in Ripe and this is the > only reasons for your emails to me. > > There is no talking sense into this person. He is oblivious to how the > internet works and how hardware and software upgrades are implemented > and deployed. Obviously pointing out his flaws means I have an illegal > interest somehow. > > I think Elad has already tried following Trump's recent advice and we > are seeing the consequences? > > Time to move on? > Sander > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Sun Apr 26 13:25:42 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Sun, 26 Apr 2020 11:25:42 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: , <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> , , <5393a4c1038d40798cc0cf66656f83ef@safehosts.co.uk> , <5fea3db6d3ab4b2bb08af999625b0238@safehosts.co.uk> , <66e746fe7a2347aa949052fab698da45@safehosts.co.uk> Message-ID: <30ac4c417cf844d2a21788191b210f3d@safehosts.co.uk> What makes you think Cisco want IPv4+ addresses? Can you conceive how many IPv6 addresses they already have? Please, for the love of sanity, stop replying and keeping this thread going, this is not the place to thrash out your concept. You have been given many examples of issues with your idea and you solve them all by saying companies like Cisco will happily upgrade EOL products along with all existing and future products to obtain some IPv4+ addresses. We all know this is nonsense. Please, stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 12:20 To: Stuart Willet (primary) ; Sander Steffann Cc: Gert D?ring ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Cisco as part of the round table, will receive high amount of IPv4+ addresses, they are equally worth to money. You wrote millions of dollars 100,000,000 new IPv4 addresses (from IPv4+) that will be provided to everyone involved including ASN's and ISP's and Operating System vendors and netowrking equipment manufacturers - are worth in total 2 Billion USD , this is much more than the few millions dollars that you wrote. " If providers have not implemented IPv6 on EOL devices, why on earth would they implement IPv4+?" - because I believe that there will be pressure from the community and it will be benefited to them. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:56 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You STILL don't see the issue? Who is going to pay for all the development? How will Cisco provide updates for EOL kit? This is ONLY a partial list of Cisco kit. There will be thousands of devices from different suppliers which are EOL and will need someone to work out how to update them. This would cost millions of dollars to do worldwide, it just isn't practical. If providers have not implemented IPv6 on EOL devices, why on earth would they implement IPv4+? EOL = End Of Life, unsupported. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:52 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Any home-modem will not need to be updated (no matter if it is L2 or L3). Regarding the EOL list you provided, Cisco will be part of the round table (just like any other routing equipment manufacturer) and firmware upgrades will be provided by any round table member even for its EOL products so the deployment of IPv4+ will be possible. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:48 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You keep saying "Any home modem will not need to be updated at all" and you keep saying switches are L2. My home modem is a L3 device. There are a lot of L3 switches which have hit end of life in lots of data centres around the world. Regardless of how many times you SAY these are L2 switches, they are not. By way of example, here is just a handful of Cisco's EOL Layer 3 (IP based) devices which would need some kind of upgrade or replacement: Cisco 6000 Series IP DSL Switches Cisco Blade Switches for Dell Cisco Blade Switches for HP Cisco Catalyst 3750 Series Switches Cisco Catalyst 3750-X Series Switches Cisco Catalyst 3560 Series Switches Cisco Catalyst 3560-C Series Switches Cisco Catalyst 3560-X Series Switches Cisco Catalyst 2960 Series Switches Cisco Catalyst 2960-S Series Switches Cisco Catalyst 2960-SF Series Switches Cisco Catalyst 2955 Series Switches Cisco Catalyst 2360 Series Switches Cisco Energy Management Suite Cisco ME 4600 Series Multiservice Optical Access Platform Cisco ME 3800X Series Carrier Ethernet Switch Routers Cisco ME 3600X Series Ethernet Access Switches Cisco ME 3400E Series Ethernet Access Switches Cisco ME 2600X Series Ethernet Access Switches Cisco Nexus 4000 Series Switches Cisco Nexus 1100 Series Cloud Services Platforms Cisco Small Business 500 Series Stackable Managed Switches Cisco Small Business 100 Series Unmanaged Switches Cisco Switch Modules for IBM Cisco Virtual Application Cloud Segmentation (VACS) Services Citrix NetScaler 1000V Remember, this is only Cisco and only a partial list. You will need to add Juniper, HP, Dell, D-Link, Alcatel, Foundry, Marconi, Nortel and many many more. You will also need to update EVERY distro of Linux, Unix, Windows and other more bespoke operating systems. Best, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:18 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world I already answered to you one minute ago. No software update will need to be done to any modem, I wrote it many many times but you ignored it - so please don't blame it on me. Here is again: Any home modem will not need to be updated at all Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:16 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Show me how to "software update" my BT modem to accept iPv4 (rhetorical) I'm sorry, but you have had plenty of feedback from lots of people. You refuse to see the obvious, nobody is going to spend the man hours required. I am now respectfully bowing out, I have wasted enough time on this. Please feel free to tell people I am part of an IPv6 conspiracy against you, but also accept that this is nonsense. Best regards, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:07 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world But you didn't understand IPv4+ based on what you are writing or you are trying to influence the readers... First fully understand something, then decide if you are against it or not. Regarding: "you want millions of dollars spent on millions of upgrades for a handful of new IPv4 addresse" No hardware upgrades will be need, only software updates and the software developers (operating system vendors and routing equipment manufacturers) will receive incentives. End-users / companies / organizations - will need to invest nothing. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 1:03 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world You have not convinced me, I make no money from IPv6. I have no incentive to push IPv6 or downplay IPv4 or IPV4+ Your idea is flawed and that's that. Sorry, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 26 April 2020 11:00 To: Stuart Willet (primary) >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Stuart, The people that responded are not reflecting the opinion of the vast majority of internet companies and internet organizations - which needs IPv4. Each and every person that I wasn't able to convince as you wrote is an active deployer of IPv6 and earns his money from deploying IPv6. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Sunday, April 26, 2020 12:54 PM To: Elad Cohen >; Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net > Subject: RE: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, You are now making yourself look a little paranoid and silly. Respectfully, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 26 April 2020 10:53 To: Sander Steffann > Cc: Gert D?ring >; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home... * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhe at nosc.ja.net Sun Apr 26 13:28:59 2020 From: rhe at nosc.ja.net (Rob Evans) Date: Sun, 26 Apr 2020 12:28:59 +0100 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: Message-ID: Hi Elad, It?s an interesting idea, but I fear we have gone through similar proposals to sneak an extra bit out of the IPv4 header and double the number of addresses in the past, and they have all come unstuck somewhere. One of the biggest issues I see is that on most routers, at both the low and the high end, much of the forwarding is performed in silicon rather than in software. The design cycle for the silicon is long and expensive, and the replacement cycle even longer ? think years rather than weeks or months. Almost all of that silicon can already handle IPv6. How are routing protocols going to transport IPv4+ routes? How will IPv4+ addresses be stored in the DNS? I assume this will require a new record type that will have to be deployed by DNS servers worldwide. I also think you underestimate the length of time to push out updates to software worldwide. Many people use operating systems and applications that are no longer supported, perhaps because the hardware they are using them on is no longer supported. It?s not just the IP stack that needs to change, it is anywhere that displays or accepts an IP address, so that?s everything from web forms to web browsers to system preferences boxes. The path MTU discovery relies on a timeout, so it will add to connection setup times, which will make applications slow down unacceptably. It also only copes with the MTU decreasing during the lifetime of a session (also relying on another timeout), not increasing. The proposal uses UDP to determine an MTU that could be used for TCP, yet it?s possible that the two protocols could take different paths if there?s some application-specific filtering happening. We don?t really need ?another IPv4?s worth of IP addresses,? especially if that just perpetuates deployment of IPv4 rather than IPv6. According to internetworldstats.com, they believe that just under 60% of the world?s population has Internet access in one form or other. We need a system that can cope with not just the additional 40%, but increasingly the ?Internet of Things,? and we have that ? IPv6. The effort would be better expended on deploying IPv6 than repeating the same work for a short-term band-aid. As others have said, the IETF is the place to standardise this, if you wish to attempt to do so. It would certainly be worth reading up on how other recent alternative schemes have faired (e.g. Khaled Omar's "IPv10" proposal to enable IPv4/IPv10 inter-operation). Cheers, Rob From elad at netstyle.io Sun Apr 26 13:29:10 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 11:29:10 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: <143d4ae2f3f1410280104e719eb4aac7@aaa-exchg01.aaa-sales.local> References: , <678a5821-de4d-a75d-d74f-5af21c07fe11@lenfiber.it> , <143d4ae2f3f1410280104e719eb4aac7@aaa-exchg01.aaa-sales.local> Message-ID: Dear Jurgen, Your message is great, if there would be more like these we would probably be in the path for IPv4+ I have answers for most of your questions, the rest I need to look into more. The main issue is if the community is open for it or not. I will get back to you on everything you wrote. Please forgive me everyone, I need to complete the post for the technical solution to completely resolve "Email Spam" that will annihilate the illegal anonymous organization "The Spamhaus Project" and I want to post it today. Respectfully, Elad ________________________________ From: J?rgen Jaritsch (juergen.jaritsch at jmpts.ch) Sent: Sunday, April 26, 2020 2:07 PM To: Elad Cohen ; members-discuss at ripe.net Subject: AW: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Dear Elad, do you know what a ASIC is? Do you know how non-software defined registers work? Let's make it very easy for everyone: Do you ever thought about thinks like firewalls/loadbalancers and their GUIs? About software, that verifies IP-addresses by regex? Your idea is not compatible with existing software. Please share some detailed examples how to bypass such issues. EVEN if the hardware of the (e.g.) firewalls is able to handle the "new" IP addresses of IPv4+: the GUI have to be fixed/updated - on EVERY firewall around the world. Otherwise you'll never have any end-to-end IPv4+ connection. Same counts for software like Webservers (e.g. Apache virtual hosts can refer to IPs in the config), IPTables, databases systems, etc etc. All this software depends on existing network stack but also have configuration verification/testing processes which will not work with (unexpected) IPv4+ addresses in the configuration. What about DHCP, DNS, BGP, Peering fabrics (AMSIX,DECIC, etc) etc? This have to be adapted too. Regarding your "switches are L2 only" statement: did you ever heard about MPLS- and/or L3-switches? They could be EOL/EOS but have full support for IPv4/IPv6 so there is no real statement against using them in existing (closed/company) networks (beside the case of defective hardware). Users of this device will not receive updates from the vendors. What about big vendors? You said it's "easy" and "cheap" to implement: what if hardware line cards like Juniper MPC does not support this? This cards are used in many backbone routers. Should the carriers simple replace them? To be honest: from a theoretical point of view your idea sounds great, but you have to consider way more details / functions / devices / situations /implementations. Your idea is nothing simple to "activate" like an feature. You can't tell a carrier "if your Juniper MPC does not support IPv4+, you have to use NAT" - seriously? With hundreds if Gbps? Best regards J?rgen Von: members-discuss Im Auftrag von Elad Cohen Gesendet: Sonntag, 26. April 2020 12:38 An: Thomas Gallo @ Lenfiber S.p.A. ; members-discuss at ripe.net Betreff: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world ASICs or any device with a similar problem, can be connected to the internet through a NAT router, the NAT router will help the ASIC or the similar device with IPv4+ (The ASIC or the similar device will only be able to initiate connections to IPv4, but any ip addresses in the internet - IPv4 or IPv4+ will be able to initiate a connection to the ASIC or the similar device and then to create a session with it, the NAT router will monitor the session and will set the IPv4+ bits accordingly) In advanced configuration in the NAT router there can be an option that all ip packets that will originate from the specific ASIC will be only to IPv4+ addresses (and not to IPv4) so the NAT router will always set the IPv4+ related bits in any ip packet originated from the ASIC or similar device. Respectfully, Elad ________________________________________ From: members-discuss on behalf of Thomas Gallo @ Lenfiber S.p.A. Sent: Sunday, April 26, 2020 1:03 PM To: mailto:members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, many years ago it could have been a good idea.. but even if all of this could be implemented on the software side today... but what about ASICs and so forth? (thinking to circuitry that do lookup based on 32bits for example) Best regards, Thomas Il 26/04/2020 11:52, Elad Cohen ha scritto: Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert D?ring; mailto:members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home. * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections _______________________________________________ members-discuss mailing list mailto:members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/thomas.gallo%40lenfiber.it -- Thomas Gallo email: mailto:thomas.gallo at lenfiber.it Amministratore unico Lenfiber S.p.A. Centro Direzionale Interporto Padova - Torre B Galleria Spagna, 36 - 35127 Padova (PD) ph: +39 049 85 94 766 fax: +39 049 82 51 032 P.Iva/VAT: IT04669150288 Cap.Soc. 200.000,00 Euro i.v. http://www.lenfiber.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at slimey.org Sun Apr 26 13:38:46 2020 From: simon at slimey.org (Simon Lockhart) Date: Sun, 26 Apr 2020 12:38:46 +0100 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <7cf72d19b7014ea89540b0138077f990@safehosts.co.uk> <5393a4c1038d40798cc0cf66656f83ef@safehosts.co.uk> <5fea3db6d3ab4b2bb08af999625b0238@safehosts.co.uk> <66e746fe7a2347aa949052fab698da45@safehosts.co.uk> Message-ID: <20200426113846.GT1189@dilbert.slimey.org> On Sun Apr 26, 2020 at 11:19:48AM +0000, Elad Cohen wrote: > 100,000,000 new IPv4 addresses (from IPv4+) that will be provided to everyone > involved including ASN's and ISP's and Operating System vendors and > netowrking equipment manufacturers - are worth in total 2 Billion USD , this > is much more than the few millions dollars that you wrote. No, IPv4 addresses attract a high premium price because of their scarcity. Make lots of them available (much like IPv6 does) means that they'll have no market value. It does seem like your proposal is about 'printing' more IPv4 addresses so that IPv4 brokers can make more money out of them. Simon From paul at prtsystems.ltd.uk Sun Apr 26 13:55:52 2020 From: paul at prtsystems.ltd.uk (Paul Thornton) Date: Sun, 26 Apr 2020 12:55:52 +0100 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426104228.GL90387@carcass.ledeuns.net> Message-ID: On 26/04/2020 12:11, Elad Cohen wrote: > ...you don't need to implement a protocol in order to > prove it works, ... I think you will find that this is *exactly* how new protocols are introduced to the community. People get a working prototype running and can show (1) that it works and (2) that its perceived benefits outweigh its potential flaws. Paul. From campbell at inca.ie Sun Apr 26 15:43:24 2020 From: campbell at inca.ie (Ed Campbell) Date: Sun, 26 Apr 2020 14:43:24 +0100 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426104228.GL90387@carcass.ledeuns.net> Message-ID: I?m not sure what is going on here but someone tried to remove me from this list?. You know who you are ... Mailing list removal confirmation notice for mailing list members-discuss We have received a request from 188.26.42.62 for the removal of your email address, "campbell at inca.ie " from the members-discuss at ripe.net mailing list. To confirm that you want to be removed from this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 15:45:17 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 13:45:17 +0000 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426104228.GL90387@carcass.ledeuns.net> , Message-ID: Someone tried to do it to me as well. Respectfully, Elad ________________________________ From: members-discuss on behalf of Ed Campbell Sent: Sunday, April 26, 2020 4:43 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world I?m not sure what is going on here but someone tried to remove me from this list?. You know who you are ... Mailing list removal confirmation notice for mailing list members-discuss We have received a request from 188.26.42.62 for the removal of your email address, "campbell at inca.ie" from the members-discuss at ripe.net mailing list. To confirm that you want to be removed from this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjw at digiware.nl Sun Apr 26 15:50:47 2020 From: wjw at digiware.nl (Willem Jan Withagen) Date: Sun, 26 Apr 2020 15:50:47 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426104228.GL90387@carcass.ledeuns.net> Message-ID: <5a093bab-9eff-fad8-1b0d-b87307f5dcac@digiware.nl> On 26-4-2020 13:55, Paul Thornton wrote: > > On 26/04/2020 12:11, Elad Cohen wrote: > >> ...you don't need to implement a protocol in order to >> prove it works, ... > > I think you will find that this is *exactly* how new protocols are > introduced to the community.? People get a working prototype running > and can show (1) that it works and (2) that its perceived benefits > outweigh its potential flaws. I'm having a very hard time envisioning the "easy" software application changes that are required to support this. All ipv4 code depends on the fact an ipv4 address is 4 bytes. All ipv6 code depends on the fact an ipv6 address is 16 bytes. Now this requires either 1 extra bit somewhere, or another structure describing ipv4+ in sockaddr. So for this idea to be workable, implementations are the only thing that are going to convince application developers to jump on the bandwagon. And that'll be the same struggle af for IPv6. And as long as the likes of github.com don't even do ipv6, I very much doubt that ipv4+ is going to go anywhere.? Let alone that it will arrive there faster. So instead of going after "yet another pot of gold", lets get IPv6 going. just my 2 cts. --WjW From a.morreale at tradingnetwork.it Sun Apr 26 15:56:29 2020 From: a.morreale at tradingnetwork.it (TNC - Alessandro Morreale) Date: Sun, 26 Apr 2020 15:56:29 +0200 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426104228.GL90387@carcass.ledeuns.net> Message-ID: <74c876ad-762e-b773-4224-2af50efc00dc@tradingnetwork.it> And someone re-added me Please, have mercy on me! Il 26/04/20 15:45, Elad Cohen ha scritto: > Someone tried to do it to me as well. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* members-discuss on behalf > of Ed Campbell > *Sent:* Sunday, April 26, 2020 4:43 PM > *To:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] Technical solution to resolve the > IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 > addresses that are needed in the world > I?m not sure what is going on here but someone tried to remove me from > this list?. > > > You know who you are ... > > > > Mailing list removal confirmation notice for mailing list > members-discuss > > We have received a request from 188.26.42.62 for the removal of your > email address, "campbell at inca.ie " from the > members-discuss at ripe.net > mailing list. ?To confirm that you want to be removed from this > mailing list, simply reply to this message, keeping the Subject: > header intact. ?Or visit this web page: > > > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/a.morreale%40tradingnetwork.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 18:05:36 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 16:05:36 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Message-ID: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at cowmedia.de Sun Apr 26 18:22:39 2020 From: info at cowmedia.de (info at cowmedia.de) Date: Sun, 26 Apr 2020 18:22:39 +0200 Subject: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: Message-ID: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> Sorry Elad, i know ist Sunday and some members of this mailling list have more time as on a busy working day but are you really again (see the other topic) posting an idea in this list were we cannot do anything about this? You try to find or present solutions to problems that doesnt exist. While you think a lot on your ideas technically, please note that this is only 1/3 of the things you need to take care of. In this specific case you want to outsource the servers job of filtering SPAM out competely to the client. This is not how this was designed. You are thinking that email clients always have a UI or at least some bigger code behind it that is able to do a lot of stuff. There exist email clients in the world that have only <100 lines of code and are only text based (as email is from the ground up). We are completely the wrong audience group for your emails. Michael Von: members-discuss Im Auftrag von Elad Cohen Gesendet: Sonntag, 26. April 2020 18:06 An: members-discuss at ripe.net Betreff: [SPAM] [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Viol ation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" ( http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5533 bytes Desc: not available URL: From silvan at unavailable.online Sun Apr 26 18:29:30 2020 From: silvan at unavailable.online (Silvan Gebhardt) Date: Sun, 26 Apr 2020 16:29:30 +0000 Subject: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> References: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> Message-ID: <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online> Hi Michael, this is not about any technical solution. This is Elad trying to position himself for the upcoming election. This is an election campaign. Nothing more. https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates Elon, just save your next typing. You will immead scream that I am running an "illegal cyber defamation campaign" against you. Sure. whatever. Silvan On 4/26/20 4:22 PM, info at cowmedia.de wrote: > > Sorry Elad, > > ? > > i know ist Sunday and some members of this mailling list have more > time as on a busy working day but are you really again (see the other > topic) posting an idea in this list were we cannot do anything about this? > > ? > > You try to find or present solutions to problems that doesnt exist. > While you think a lot on your ideas technically, please note that this > is only 1/3 of the things you need to take care of. > > In this specific case you want to outsource the servers job of > filtering SPAM out competely to the client. This is not how this was > designed. You are thinking that email clients always have a UI or at > least some bigger code behind it that is able to do a lot of stuff. > There exist email clients in the world that have only <100 lines of > code and are only text based (as email is from the ground up). > > ? > > We are completely the wrong audience group for your emails. > > ? > > Michael > > ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 18:37:48 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 16:37:48 +0000 Subject: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online> References: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de>, <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online> Message-ID: Silvan, You didn't even read the technical solution that I wrote, maybe you will read it first ? Respectfully, Elad ________________________________ From: members-discuss on behalf of Silvan Gebhardt Sent: Sunday, April 26, 2020 7:29 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem Hi Michael, this is not about any technical solution. This is Elad trying to position himself for the upcoming election. This is an election campaign. Nothing more. https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates Elon, just save your next typing. You will immead scream that I am running an "illegal cyber defamation campaign" against you. Sure. whatever. Silvan On 4/26/20 4:22 PM, info at cowmedia.de wrote: Sorry Elad, i know ist Sunday and some members of this mailling list have more time as on a busy working day but are you really again (see the other topic) posting an idea in this list were we cannot do anything about this? You try to find or present solutions to problems that doesnt exist. While you think a lot on your ideas technically, please note that this is only 1/3 of the things you need to take care of. In this specific case you want to outsource the servers job of filtering SPAM out competely to the client. This is not how this was designed. You are thinking that email clients always have a UI or at least some bigger code behind it that is able to do a lot of stuff. There exist email clients in the world that have only <100 lines of code and are only text based (as email is from the ground up). We are completely the wrong audience group for your emails. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From haisoft at haisoft.net Sun Apr 26 18:31:56 2020 From: haisoft at haisoft.net (Frederic Vagner) Date: Sun, 26 Apr 2020 18:31:56 +0200 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: Message-ID: Hello, I'm not sure if you are aware but SPF is doing something similar but a lot easier to setup : it tells all the servers to accept or deny an email depending on the server sending it. Unfortunately for SPF, just like your system, everyone is not using it. If every domain was using SFP properly, all webservers could simply block emails sent through unauthorized servers and that'd be it ! But people are just not concerned enough to setup SPF on all their domains and domains without SPF setup properly or just not setup are the ones used to send spam and succeeding ... So sad ... Have a nice day ! (and I'm not sure this mailing list is here to discuss enhancement to The Internet, there are other places to better do that, I'm sure) Frederic Vagner HaiSoft From silvan at unavailable.online Sun Apr 26 18:45:45 2020 From: silvan at unavailable.online (Silvan Gebhardt) Date: Sun, 26 Apr 2020 16:45:45 +0000 Subject: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online> Message-ID: Hi Elad, There are many smart people on this world. I've been in IT for too long. If someone tells me they have a "technical solution" to spam I don't buy it because it's either so convoluted we can rather just turn email litterally off (as in, stop accepting email, close port 25 and go back to a "closed" world - like back in the days of compuserve? Where you get to-down-control. Reminds me of "New IP" with the top-down control. I read it to the point of reading about a centralized website, and stopped there? We do not want top down control in this place, so obviously any top down control is doomed to fail from my point of view. The solution to spam is education. if people finally would stop falling for 419 Scams, they would cease to be if people would finally stop buying viagra online, they would cease to be spammed for if people would fall for the fake bride scams, I would not receive boobies by email anymore. but unfortunately, it seems at some of the spammers customers think with their genitals instead of their brain still. You can't fix this with a technical solution. so, make the customers go away by learning, the business dies down. simple economics. I belive in simple economics. BR Silvan On 4/26/20 4:37 PM, Elad Cohen wrote: > Silvan, > > You didn't even read the technical solution that I wrote, maybe you > will read it first ? > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* members-discuss on behalf > of Silvan Gebhardt > *Sent:* Sunday, April 26, 2020 7:29 PM > *To:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] [SPAM] Technical Solution to resolve > the global "Email Spam" problem > ? > > Hi Michael, > > > this is not about any technical solution. This is Elad trying to > position himself for the upcoming election. > > This is an election campaign. Nothing more. > > > https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates > > > Elon, just save your next typing. You will immead scream that I am > running an "illegal cyber defamation campaign" against you. Sure. > whatever. > > > > Silvan > > On 4/26/20 4:22 PM, info at cowmedia.de wrote: >> >> Sorry Elad, >> >> ? >> >> i know ist Sunday and some members of this mailling list have more >> time as on a busy working day but are you really again (see the other >> topic) posting an idea in this list were we cannot do anything about >> this? >> >> ? >> >> You try to find or present solutions to problems that doesnt exist. >> While you think a lot on your ideas technically, please note that >> this is only 1/3 of the things you need to take care of. >> >> In this specific case you want to outsource the servers job of >> filtering SPAM out competely to the client. This is not how this was >> designed. You are thinking that email clients always have a UI or at >> least some bigger code behind it that is able to do a lot of stuff. >> There exist email clients in the world that have only <100 lines of >> code and are only text based (as email is from the ground up). >> >> ? >> >> We are completely the wrong audience group for your emails. >> >> ? >> >> Michael >> >> ? >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 18:33:00 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 16:33:00 +0000 Subject: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> References: , <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> Message-ID: Michael, Handling SPAM wasn't designed anywhere, and we can see the results of how SPAM is currently handled - email spammers are winning. "You try to find or present solutions to problems that doesnt exist" - Spam problem doesn't exist ? An optional implementation can be made for the email server, so it will work with the kind of non-gui email clients of less than 100 lines of code. Respectfully, Elad ________________________________ From: members-discuss on behalf of info at cowmedia.de Sent: Sunday, April 26, 2020 7:22 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem Sorry Elad, i know ist Sunday and some members of this mailling list have more time as on a busy working day but are you really again (see the other topic) posting an idea in this list were we cannot do anything about this? You try to find or present solutions to problems that doesnt exist. While you think a lot on your ideas technically, please note that this is only 1/3 of the things you need to take care of. In this specific case you want to outsource the servers job of filtering SPAM out competely to the client. This is not how this was designed. You are thinking that email clients always have a UI or at least some bigger code behind it that is able to do a lot of stuff. There exist email clients in the world that have only <100 lines of code and are only text based (as email is from the ground up). We are completely the wrong audience group for your emails. Michael Von: members-discuss Im Auftrag von Elad Cohen Gesendet: Sonntag, 26. April 2020 18:06 An: members-discuss at ripe.net Betreff: [SPAM] [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 18:49:03 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 16:49:03 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: , Message-ID: Hello, In email servers, even if they have SPF check configured, DMARC DNS record can override it (if DMARC DNS record is not set or if the field p value in DMARC DNS record value is "none", nothing will happen by the email server even if the SPF check will fail), it means that any domain owner can allow (using the DMARC DNS record) for any email address of his domain to be spoofed by any attacker in the internet, to my opinion the user needs to be fully protected in his email client due to it and also to check regarding SPF in his email client (and not to rely on the email server which is relying on DMARC DNS record which is set by the domain owner). Respectfully, Elad ________________________________ From: members-discuss on behalf of Frederic Vagner Sent: Sunday, April 26, 2020 7:31 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hello, I'm not sure if you are aware but SPF is doing something similar but a lot easier to setup : it tells all the servers to accept or deny an email depending on the server sending it. Unfortunately for SPF, just like your system, everyone is not using it. If every domain was using SFP properly, all webservers could simply block emails sent through unauthorized servers and that'd be it ! But people are just not concerned enough to setup SPF on all their domains and domains without SPF setup properly or just not setup are the ones used to send spam and succeeding ... So sad ... Have a nice day ! (and I'm not sure this mailing list is here to discuss enhancement to The Internet, there are other places to better do that, I'm sure) Frederic Vagner HaiSoft _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/elad%40netstyle.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fido.net Sun Apr 26 18:50:36 2020 From: jon at fido.net (Jon Morby) Date: Sun, 26 Apr 2020 16:50:36 +0000 (UTC) Subject: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: Message-ID: <1056060662.1498519.1587919836718.JavaMail.zimbra@apps-store-3> Tbh since the onset of the global pandemic and subsequent lockdown I?ve seen a huge decrease in both the amount of junk mail I receive and also the number of unsolicited phone calls I?m getting. It?s as if an entire continent has been told not to go outside, or even go to work, and very few of them have broadband available at home ... (or has a disaster recovery it plan in place) Anyway I confess I?ve switched off from most of these threads now but I sure know who I won?t be voting for as a result of the lengthy thread, so I guess some good has come from all of this :) ? Jon Morby > On 26 Apr 2020, at 17:46, Silvan Gebhardt wrote: > > ? > Hi Elad, > > > > There are many smart people on this world. I've been in IT for too long. If someone tells me they have a "technical solution" to spam I don't buy it because it's either so convoluted we can rather just turn email litterally off (as in, stop accepting email, close port 25 and go back to a "closed" world - like back in the days of compuserve? Where you get to-down-control. > > > > > > Reminds me of "New IP" with the top-down control. > > I read it to the point of reading about a centralized website, and stopped there > > > > We do not want top down control in this place, so obviously any top down control is doomed to fail from my point of view. > > > The solution to spam is education. > if people finally would stop falling for 419 Scams, they would cease to be > > if people would finally stop buying viagra online, they would cease to be spammed for > > if people would fall for the fake bride scams, I would not receive boobies by email anymore. > > > > but unfortunately, it seems at some of the spammers customers think with their genitals instead of their brain still. You can't fix this with a technical solution. > > > > > > so, make the customers go away by learning, the business dies down. simple economics. I belive in simple economics. > > BR > Silvan > > > >> On 4/26/20 4:37 PM, Elad Cohen wrote: >> Silvan, >> >> You didn't even read the technical solution that I wrote, maybe you will read it first ? >> >> Respectfully, >> Elad >> From: members-discuss on behalf of Silvan Gebhardt >> Sent: Sunday, April 26, 2020 7:29 PM >> To: members-discuss at ripe.net >> Subject: Re: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem >> >> Hi Michael, >> >> >> >> this is not about any technical solution. This is Elad trying to position himself for the upcoming election. >> >> This is an election campaign. Nothing more. >> >> >> >> https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates >> >> >> >> Elon, just save your next typing. You will immead scream that I am running an "illegal cyber defamation campaign" against you. Sure. whatever. >> >> >> >> >> >> Silvan >> >>> On 4/26/20 4:22 PM, info at cowmedia.de wrote: >>> Sorry Elad, >>> >>> i know ist Sunday and some members of this mailling list have more time as on a busy working day but are you really again (see the other topic) posting an idea in this list were we cannot do anything about this? >>> >>> You try to find or present solutions to problems that doesnt exist. While you think a lot on your ideas technically, please note that this is only 1/3 of the things you need to take care of. >>> In this specific case you want to outsource the servers job of filtering SPAM out competely to the client. This is not how this was designed. You are thinking that email clients always have a UI or at least some bigger code behind it that is able to do a lot of stuff. There exist email clients in the world that have only <100 lines of code and are only text based (as email is from the ground up). >>> >>> We are completely the wrong audience group for your emails. >>> >>> Michael >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias at brumm.net Sun Apr 26 18:50:23 2020 From: matthias at brumm.net (Matthias Brumm) Date: Sun, 26 Apr 2020 18:50:23 +0200 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: Message-ID: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> Hi! To understand correctly. You want to enforce, that every subscribe operation / e-mail client operation (get new email from server) in the world will make a bidirectional communication with a central server? Do you have an ellaborated guess, how much computing power that would need? Matthias Am 26.04.20 um 18:05 schrieb Elad Cohen: > Hello Everyone, > > I want to share with you my technical solution to resolve the global > world "Email Spam" problem and in addition it will also resolve the > spreading of illegal links (phishing/malware/etc , once the sites are > known) through electronic mail and will stop email spoofing (that part > using current technologies). > > Email spam problem was not being able to be defeated since the > beginning of electronic mail, as long as email spam will be profitable > to email spammers - it will exist, email spam caused the illegal > anonymous organization "The Spamhaus Project" to exist, "The Spamhaus > Project" is hurting and damaging many businesses worldwide in their > way to fight email spam, "The Spamhaus Project" is an illegal > anonymous organization according to the following presentation that > they wrote on themselves, they are violating laws in their way to > fight email spam and still they don't win in the battle against email > spam. "The Spamhaus Project" is keeping their anonymity because they > are afriad of justified lawsuits due to their criminal actions in > their way to fight email spam. The following technical solution will > resolve the world email spam problem without to hurt and to damage > many businesses worldwide that have nothing to do with email spam like > "The Spamhaus Project" does, the following implementation can remove > the need for an illegal anonymous organization such as "The Spamhaus > Project". > > > The presentation that the illegal anonymous organization "The Spamhaus > Project" wrote on themselves: > https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation > > > > The Implementation: > > There will be a site (lets call it NoSpam.org) - the site will be > owned by the 5 RIRs, the site will use bgp anycast and will be > deployed in each of the 5 RIRs (the site will also be able to be > deployed by the ccTLD registries in each country), the site in all the > locations will be synced automatically. > > Each domain owner will be able to register at the site (an email > message will be sent to the domain owner email address in the domain > name WHOIS details in order to verify that the domain owner is the one > registering). > > After being logged in, a domain owner will be able to add his email > addresses (of the specific domain name) that will be used to send > newsletters / mailing lists / one-to-many email messages, lets call > these kind of email addresses as 'mailing list' email addresses. The > domain owner will not be able to see the list of 'mailing list' email > addresses that he added - because when he added each 'mailing list' > email address it will be saved with hash in the NoSpam.org backend > infrastructure (due to privacy and security reasons) - hence only if > the domain owner will manually type the 'mailing list' email address > he will be able to enter it in order to manage it (to see the total > number of subscribers email addresses, to see the subscribers email > addresses but only with their hashes due to security and privacy > reasons, to remove a subscriber from the list, to add a sub-user with > permissions to manage that specific 'mailing list' email address). > > In his site, the domain owner will be able to integrate an iframe from > NoSpam.org (or to connect to NoSpam.org with ajax) regarding a > subscriber registration form to his specific 'mailing list' email > address, the subscriber will receive an email message with a link to > confirm his subscription. > > The domain owner will need to create a callback file in his website, > for example in the path: "/nospam-notification-callback" > (http://example.com/nospam-notification-callback) - that url will > receive encrypted post notifications (encryption key will be provided > by the domain owner in his NoSpam.org logged in account) from > NoSpam.org regarding any new end-user that will subscribe or that will > unsubscribe from a 'mailing address' email address which is related to > the domain of the domain owner (unsubscribe functionality by the user > later below). > > The subscriber email address and that 'mailing list' email address > (that was subscribed to) will be sent by NoSpam.org to > "/nospam-notification-callback" not in the hashed format but in > cleartext (so the domain owner will be able to save it in his system > for future email messages from the specific 'mailing list' email > address to the specific subscriber email address). > > The domain owner will also have an API to NoSpam.org backend > infrastructure in order to remove a specific subscriber email address > from a specific 'mailing list' email address (the domains owner will > send the values through the API - hashed). > > The domain owner will also provide a web interface in his site for the > end-user to remove himself from the specific 'mailing list' email address. > > > > The above is the backend implementation (no upgrade is needed to any > email server in the internet), the following is the upgrade that will > needed for any email client (that upgrade is not mandatory, without > the following upgrade the email client will work exactly as it is now > without the added no-spam features, electronic mail will not break if > some email users will upgrade their email clients and some will not): > > - There will not be 'mark as spam' button, that kind of functionality > will stop to exist because spam is not a boolean value, 'spam' to one > person is valuable to another 'person', specially when the internet is > global and different people from different countries will consider > spam content differently. One user can consider an email message as > spam and another user can consider the same message as not spam, > 'Spam' is subjective and any kind of 'mark as spam' functionality is > useless in the battle against email spam. > > - There will be blacklists and whitelists (just like there are now, > but they will be more prominent): blacklist email addresses , > blacklist domains , whitelist email addresses , whitelist domains. > > - The end-user should be able to easily enter each email message to > whitelist or to blacklist (meaning the 'from' email address of the > email message), and will be able to search in the 'Spam' folder easily > for an email address (these features can exist today, but they should > be given more visibility, so end-users will use them more). > > - The end-user will be able to import/export his whitelists and > blacklists using an xml format to any other upgraded email client, the > blacklists and whitelists will be local (end-user will be able to pass > the local whitelists and blacklists to another email client of his > with the click of a button in the upgraded email client - the upgraded > email client will just send them to itself - without to download them > from the email server so the end-user will be able to download it with > another upgraded email client - or the end-user will be able to send > the whitelists and blacklists to another email address of him, the > usage will not be like sending regular email message with attachments > - the upgraded email clients will take care to sending and receiving > of the blacklists and whitelits - in the background, these are custom > formatted email messages that the two upgraded email clients will know > how to act upon them). > > - The email client will be able to display with GUI with buttons any > 'mailing-list registration confirmation email' in a specific section > related to registration to new 'mailing list' email addresses for the > end-user to choose with buttons if he accept or refuse to register to > a specific 'mailing list' email address. > > - For any email message that was received: in case a received 'from' > email address was found in the whitelist email addresses or in the > whitelist domains - then it will be moved to the 'Inbox' folder, in > case the 'from' email address of the email message was found in the > blacklist email addresses or in the blacklist domains - then the email > message will be moved to the 'Trash' folder. > > - In case the 'from' email address or domain was not found in the > whitelists and in the blacklists, then the upgraded email client will > send the 'from' email address and the 'from' domain and the current > user email address and the external links that exist in the email > message (but all of these data will be sent in a hashed way, and not > in cleartext) with a query to NoSpam.org backend infrastructure, > NoSpam.org will perform the following algorithem after it: > > - If the hashed 'from' domain (or any other 'hashed' domain from the > external links) exist in a list of criminals hashed domains (of > phishing/malware/viruses/etc) then NoSpam.org will respond to the > email client to delete the email message, otherwise the hashed 'from' > email address will be checked against a list of hashed 'mailing list' > email addresses - if found then the sender is a 'mailing list' email > address and there will be a check by NoSpam.org backend infrastructure > if the hashed 'receiver' email address is a subscriber of that > specific 'mailing list' email address , if the hashed 'receiver' was > found then NoSpam.org will send a response to the email client that > the email message can be displayed in the 'Inbox' folder and in the > response NoSpam.org will also include an unsubscribe key - the email > client will be able to display an unsubscribe button to the email > client and if clicked the email client will send an https request to > NoSpam.org with the specific unsubscribe key, NoSpam.org backend > infrastructure will remove the end-user email address from the > 'mailing list' email address and will notify the domain owner at the > domain owner callback url "/nospam-notification-callback" that the > specific user unsubscribed. In case the hashed 'receiver' wasn't found > then NoSpam.org will respond to the email client to delete the email > message and NoSpam.org will also notify the callback url of the > related domain owner that he shouldn't send email messages from the > specific 'mailing ?list' email address to the specific subscriber > email address. > > - In case when NoSpam.org backend infrastructure searched the hashed > 'from' email address and it wasn't found in the list of all hashed > 'mailing list' email addresses, it mean that the email address was > sent from a 'personal' email address and NoSpam.org backend > infrastructure will notify the email client that the email message is > from a 'personal' email address - the email client in that stage will > need to decide if to move the email message to the 'Inbox' folder or > to the 'Spam' folder based on the following - the email client will > check if the email message include links/images/plain-url's - and if > yes then the email message will be moved to the 'Spam' folder, > otherwise it will be moved to the 'Inbox' folder. > > > > > Whitelist Handshake: > > - In order to facilitate the adding of new email address to the local > whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist > Handshake' is a GUI representation in two email clients regarding > background email messages between them (that the two end-users don't > see), "end-user A" with a click of a button will be able to send 'add > me to whitelist' request to "end-user B" which will be able to accept > or deny and if accepted then "end-user B" will be able to > automatically send the same "add me to whitelist" request to "end-user > A" , all of this communication will be done behind the scenes, these > special email messages will not be visible to the end-users, end-users > will see popups with GUI that email address X is asking to be added to > whitelist. In order for spammers not to abuse this option - the email > client will keep only one 'whitelist request' from each requester > email address (there will be a 'whitelist requests' section in the > upgraded email client). A repeated 'whitelist request' that came from > a specific email address can never be raised in the list (unless the > end-user will specifically search for it) even when the sender will > send more and more 'add me to whitelist' requests - no priority will > given to them, and once an end-user refused an 'add me to whitelist' > request - no new 'add me to whitelist' request will be shown from the > specific sender email address in the specific email client. > > - There can be a case that an upgraded email client will send 'add me > to whitelist' request to a not-upgraded email client and then the > receiver will see the request as it is - as an email message in the > inbox folder - due to it the content of that message will be in the > language of the domain TLD of the receiver email address and the > content in the email message will explain what is NoSpam.org and how > to upgrade the email client and supported upgraded email clients, etc > > - In the 'whitelist requests section' in the upgraded email client - > the whitelist requests will appear in a list - there should be > preference so some requests will appear upper and other lower (so > requests from spammers will appear lower) - whitelist requests from > email addresses of domains which are older (according to their WHOIS > details) will appear upper than whitelist requests from email > addresses of domains which are newer. Whitelist requests from a list > of a more-trusted-domains (domains of known webmails service, > universities, governments, etc) will have preference over other > domains, specific TLDs that not anyone can purchase will also have > preference over other TLDs that anyone can purchase (upgraded email > clients will retrieve the list of trusted TLD's and Domains each day > from NoSpam.org backend infrastructure). > > > Notification of spam emails: > > - An additional feature in the upgraded email client is that whenever > an email message will reach the 'Spam' folder - the email client will > send in the background a known-format email message to the sender and > will notify him about it, if the sender is using an upgraded email > client then it will be able to automatically send a 'add me to > whitelist' request to the receiver in the background (once an email > address is whitelisted - all the email messages from it will move from > 'Spam' to 'Inbox'). > > > > Email Spoofing: > > - In an upgraded email client, email messages from 'personal' email > addresses cannot arrive from email relay server, in case it happen the > message will be deleted and the email client will send an automatic > email message in the background to the sender with the text (in the > language of the sender domain TLD) that email messages from 'email > relay servers' cannot be received from him. > > - In an upgraded email client, email messages from 'mailing list' > email addresses can arrive from email relay servers - but they must be > encrypted with DKIM. > > - In an upgraded email client, the email client should check the SPF > txt dns record of the sender domain, and will drop the email message > if it is a spoofed email message. > > - DNS servers developers will need to make the SPF txt dns record to > be a mandatory field for every domain, in order for email spoofing to > be annihilated. > > > > Security Aspects: > > - All stored data in NoSpam.org Backend infrastructure is hashed. > > - The criminals domains list in NoSpam.org Backend Infrastructure will > be managed only by regulated supervised Law Enforcement Agency (for > example: Interpol) and not by an internet organization such as the > RIRs or ccTLD registries. > > - Domains owners will have 'forgot password' functionality to their > NoSpam.org account, the password reset link will be sent to the email > address of the owner of the domain according to the domain WHOIS details. > > - Communication between email clients to NoSpam.org backend > infrastructure will be over https, there will only be an handshake > process in the beginning over electronic mail between email client and > NoSpam.org backend infrastructure - the email client will send an > email message with a chosen key to an email address of @nospam.org > (that key will be used in further communication between the email > client and the NoSpam.org backend infrastructure over https, it will > be used for NoSpam.org backend infrastructure to identify the specific > email address over https, so anyone will not be able to query > NoSpam.org backend infrastructure to know which hashed email address > belongs to which hashed 'mailing list' email address, besides the > email client user with the right key to query NoSpam.org Backend > infrastructure only on himself). > > - Any email client will download once per day 'spam-rules' file from > NoSpam.org backend infrastructure, 'spam-rules' file will be an xml > formatted file that include rules of when to move an email message > that was received from 'personal' email address which is not > whitelisted to the 'Spam' folder (for example, when email have at > least 1/2/3 links, when email format is rich text or html and not > plaintext, etc), in case future adjustments will be needed to win the > battle against email spam - email clients will not need to be > upgraded, the new 'spam-rules' will be updated in this daily file. > > > To make it short: > > - Any email message from a subscribed mailing list / newsletter / etc > - will reach to the inbox (that kind of email messages can contain any > kind of content without any restrictions, because the user subscribed > to it and the user can unsubscribe from it at anytime). > > - Any email message from an email address or domain in whitelist - > will reach the inbox. > > - Whitelist Handshake process is easy to use and being implemented > with clicks of a button, nothing to type. > > - In case an email message will the 'Spam' folder - an automatic email > message will be sent from the receiver to sender and sender can > automatically ask to be added to the receiver's whitelist. > > - Any email message without links/images/plain-url's (plain email > messages, like electronic email was) - will reach the inbox. > > - Any other email will reach the 'Spam' folder - if needed the user > will be able to easily whitelist the email message in the 'Spam' folder. > > > > Spammers need links in their email messages for monetization, above > solution blocks it and also block criminal domains links in email > message and implement email spoofing blocking at client-side. We will > all stop to receive more than 100 spam email messages per day with the > above solution. > > > Respectfully, > Elad > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Fitzgerald at Onega.net Sun Apr 26 18:52:47 2020 From: Ben.Fitzgerald at Onega.net (Ben Fitzgerald-O'Connor) Date: Sun, 26 Apr 2020 16:52:47 +0000 Subject: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online> References: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online> Message-ID: Hi All, I generally lurk here but a small comment on this.. Reading the thread, my humble opinion: @Elad - noting the comments, I think I do agree that email problems / solutions might be better submitted as an RFC (https://www.ietf.org/standards/rfcs/) .. Ripe is a LIR mainly tasked with administering IP number resources. ... At the same time, I do love your obvious passion for addressing problems and looking freshly at possible solutions. Regarding the upcoming election - I have just had a look at the page with Candidate Biographies to judge a little how I might vote - at https://www.ripe.net/participate/meetings/gm/meetings/may-2020/candidate-biographies .. and I can't see you there, so would suggest please to submit / add a biography if this is not already in the works (and I hope all candidates do too). NB - be careful that if you do come up with a solution to fix spam once and for all then beware that you also put a USD $10 Billion value on your own head (this is the rough value annually of the anti-spam industry!) (Comment partly in jest, partly from experience and observation). I hope everyone has a good rest of the weekend. Regards Ben From: members-discuss On Behalf Of Silvan Gebhardt Sent: 26 April 2020 17:33 To: members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem Hi Michael, this is not about any technical solution. This is Elad trying to position himself for the upcoming election. This is an election campaign. Nothing more. https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates Elon, just save your next typing. You will immead scream that I am running an "illegal cyber defamation campaign" against you. Sure. whatever. Silvan On 4/26/20 4:22 PM, info at cowmedia.de wrote: Sorry Elad, i know ist Sunday and some members of this mailling list have more time as on a busy working day but are you really again (see the other topic) posting an idea in this list were we cannot do anything about this? You try to find or present solutions to problems that doesnt exist. While you think a lot on your ideas technically, please note that this is only 1/3 of the things you need to take care of. In this specific case you want to outsource the servers job of filtering SPAM out competely to the client. This is not how this was designed. You are thinking that email clients always have a UI or at least some bigger code behind it that is able to do a lot of stuff. There exist email clients in the world that have only <100 lines of code and are only text based (as email is from the ground up). We are completely the wrong audience group for your emails. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 18:53:28 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 16:53:28 +0000 Subject: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online> , Message-ID: It is useless to reply to you before you will read the whole post. What you wrote is incorrect. Respectfully, Elad ________________________________ From: Silvan Gebhardt Sent: Sunday, April 26, 2020 7:45 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem Hi Elad, There are many smart people on this world. I've been in IT for too long. If someone tells me they have a "technical solution" to spam I don't buy it because it's either so convoluted we can rather just turn email litterally off (as in, stop accepting email, close port 25 and go back to a "closed" world - like back in the days of compuserve? Where you get to-down-control. Reminds me of "New IP" with the top-down control. I read it to the point of reading about a centralized website, and stopped there We do not want top down control in this place, so obviously any top down control is doomed to fail from my point of view. The solution to spam is education. if people finally would stop falling for 419 Scams, they would cease to be if people would finally stop buying viagra online, they would cease to be spammed for if people would fall for the fake bride scams, I would not receive boobies by email anymore. but unfortunately, it seems at some of the spammers customers think with their genitals instead of their brain still. You can't fix this with a technical solution. so, make the customers go away by learning, the business dies down. simple economics. I belive in simple economics. BR Silvan On 4/26/20 4:37 PM, Elad Cohen wrote: Silvan, You didn't even read the technical solution that I wrote, maybe you will read it first ? Respectfully, Elad ________________________________ From: members-discuss on behalf of Silvan Gebhardt Sent: Sunday, April 26, 2020 7:29 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem Hi Michael, this is not about any technical solution. This is Elad trying to position himself for the upcoming election. This is an election campaign. Nothing more. https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates Elon, just save your next typing. You will immead scream that I am running an "illegal cyber defamation campaign" against you. Sure. whatever. Silvan On 4/26/20 4:22 PM, info at cowmedia.de wrote: Sorry Elad, i know ist Sunday and some members of this mailling list have more time as on a busy working day but are you really again (see the other topic) posting an idea in this list were we cannot do anything about this? You try to find or present solutions to problems that doesnt exist. While you think a lot on your ideas technically, please note that this is only 1/3 of the things you need to take care of. In this specific case you want to outsource the servers job of filtering SPAM out competely to the client. This is not how this was designed. You are thinking that email clients always have a UI or at least some bigger code behind it that is able to do a lot of stuff. There exist email clients in the world that have only <100 lines of code and are only text based (as email is from the ground up). We are completely the wrong audience group for your emails. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at cowmedia.de Sun Apr 26 19:00:25 2020 From: info at cowmedia.de (info at cowmedia.de) Date: Sun, 26 Apr 2020 19:00:25 +0200 Subject: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online> References: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online> Message-ID: <379101d61bec$2e420a00$8ac61e00$@cowmedia.de> Hi Silvan, ok maybe it seems you are right but to me this is exactly the opposite of a campaign. Maybe i know now his name, but definitive I does recognize his lazyness when it comes to things. A non-value that is not required in the Executive Board. I would definitive not vote for him. Michael Von: members-discuss Im Auftrag von Silvan Gebhardt Gesendet: Sonntag, 26. April 2020 18:30 An: members-discuss at ripe.net Betreff: Re: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem Hi Michael, this is not about any technical solution. This is Elad trying to position himself for the upcoming election. This is an election campaign. Nothing more. https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-can didates Elon, just save your next typing. You will immead scream that I am running an "illegal cyber defamation campaign" against you. Sure. whatever. Silvan On 4/26/20 4:22 PM, info at cowmedia.de wrote: Sorry Elad, i know ist Sunday and some members of this mailling list have more time as on a busy working day but are you really again (see the other topic) posting an idea in this list were we cannot do anything about this? You try to find or present solutions to problems that doesnt exist. While you think a lot on your ideas technically, please note that this is only 1/3 of the things you need to take care of. In this specific case you want to outsource the servers job of filtering SPAM out competely to the client. This is not how this was designed. You are thinking that email clients always have a UI or at least some bigger code behind it that is able to do a lot of stuff. There exist email clients in the world that have only <100 lines of code and are only text based (as email is from the ground up). We are completely the wrong audience group for your emails. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5533 bytes Desc: not available URL: From simon at slimey.org Sun Apr 26 19:04:49 2020 From: simon at slimey.org (Simon Lockhart) Date: Sun, 26 Apr 2020 18:04:49 +0100 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> Message-ID: > On 26 Apr 2020, at 17:50, Matthias Brumm wrote: > Do you have an ellaborated guess, how much computing power that would need? The billions of dollars/euros that will be generated from the creation of IPv4+ will fund the massive server infrastructure. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.jetten at elisa.fi Sun Apr 26 19:04:57 2020 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Sun, 26 Apr 2020 17:04:57 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> References: , <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> Message-ID: This list is NOT for technical related posts, it is for MEMBERSHIP related issues. Please move the discussion elsewhere. L?hetetty Outlook Mobilesta ________________________________ From: members-discuss on behalf of Matthias Brumm Sent: Sunday, April 26, 2020 7:50:23 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hi! To understand correctly. You want to enforce, that every subscribe operation / e-mail client operation (get new email from server) in the world will make a bidirectional communication with a central server? Do you have an ellaborated guess, how much computing power that would need? Matthias Am 26.04.20 um 18:05 schrieb Elad Cohen: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 19:05:15 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 17:05:15 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> References: , <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> Message-ID: Hello, Not exactly, as I wrote the site will use bgp anycast and will be deployed in the 5 RIR's locations and also by each ccTLD registry (in each ccTLD country), also load balancing can be in each place, so the traffic will be handled. "The Spamhaus Project" receive such amount of queries and they are handling it, they are just not effective but my point is that they are already handling all the queries with all the needed computing power. Respectfully, Elad ________________________________ From: members-discuss on behalf of Matthias Brumm Sent: Sunday, April 26, 2020 7:50 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hi! To understand correctly. You want to enforce, that every subscribe operation / e-mail client operation (get new email from server) in the world will make a bidirectional communication with a central server? Do you have an ellaborated guess, how much computing power that would need? Matthias Am 26.04.20 um 18:05 schrieb Elad Cohen: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 19:12:43 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 17:12:43 +0000 Subject: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online>, Message-ID: Hello Ben, Thank you very much. I don't believe that spamming will ever stop (if there is one thing that we can count on that will never change is human nature - and sadly people here believe that spammers will just stop spamming at some point), if spam will be defeated by email then spamming will be done with sms messages or by phone, currently electronic mail is the most profitable so it is most abused, and the current approaches to this problem are completely wrong - "The Spamhaus Project" are chasing after their tail, shooting everywhere, and not resolving the problem for many years. "I hope everyone has a good rest of the weekend." - Yes, I'm making sure of it. Everyone need to stay tuned because there is a new technical solution for tomorrow (how to dramatically lower DDoS attacks, a beautiful one). Respectfully, Elad ________________________________ From: members-discuss on behalf of Ben Fitzgerald-O'Connor Sent: Sunday, April 26, 2020 7:52 PM To: Silvan Gebhardt ; members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem Hi All, I generally lurk here but a small comment on this.. Reading the thread, my humble opinion: @Elad ? noting the comments, I think I do agree that email problems / solutions might be better submitted as an RFC (https://www.ietf.org/standards/rfcs/) .. Ripe is a LIR mainly tasked with administering IP number resources. ? At the same time, I do love your obvious passion for addressing problems and looking freshly at possible solutions. Regarding the upcoming election ? I have just had a look at the page with Candidate Biographies to judge a little how I might vote ? at https://www.ripe.net/participate/meetings/gm/meetings/may-2020/candidate-biographies .. and I can?t see you there, so would suggest please to submit / add a biography if this is not already in the works (and I hope all candidates do too). NB ? be careful that if you do come up with a solution to fix spam once and for all then beware that you also put a USD $10 Billion value on your own head (this is the rough value annually of the anti-spam industry!) (Comment partly in jest, partly from experience and observation). I hope everyone has a good rest of the weekend. Regards Ben From: members-discuss On Behalf Of Silvan Gebhardt Sent: 26 April 2020 17:33 To: members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem Hi Michael, this is not about any technical solution. This is Elad trying to position himself for the upcoming election. This is an election campaign. Nothing more. https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates Elon, just save your next typing. You will immead scream that I am running an "illegal cyber defamation campaign" against you. Sure. whatever. Silvan On 4/26/20 4:22 PM, info at cowmedia.de wrote: Sorry Elad, i know ist Sunday and some members of this mailling list have more time as on a busy working day but are you really again (see the other topic) posting an idea in this list were we cannot do anything about this? You try to find or present solutions to problems that doesnt exist. While you think a lot on your ideas technically, please note that this is only 1/3 of the things you need to take care of. In this specific case you want to outsource the servers job of filtering SPAM out competely to the client. This is not how this was designed. You are thinking that email clients always have a UI or at least some bigger code behind it that is able to do a lot of stuff. There exist email clients in the world that have only <100 lines of code and are only text based (as email is from the ground up). We are completely the wrong audience group for your emails. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 19:15:32 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 17:15:32 +0000 Subject: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <379101d61bec$2e420a00$8ac61e00$@cowmedia.de> References: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online>, <379101d61bec$2e420a00$8ac61e00$@cowmedia.de> Message-ID: Michael, Because I don't develop for all all the patches for the networking stacks ? maybe you will want me also to go physically router by router in all the 500,000 routers that needs to be updated and to upgrade them myself ? Respectfully, Elad ________________________________ From: members-discuss on behalf of info at cowmedia.de Sent: Sunday, April 26, 2020 8:00 PM To: 'Silvan Gebhardt' ; members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem Hi Silvan, ok maybe it seems you are right but to me this is exactly the opposite of a campaign. Maybe i know now his name, but definitive I does recognize his lazyness when it comes to things. A non-value that is not required in the Executive Board. I would definitive not vote for him. Michael Von: members-discuss Im Auftrag von Silvan Gebhardt Gesendet: Sonntag, 26. April 2020 18:30 An: members-discuss at ripe.net Betreff: Re: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem Hi Michael, this is not about any technical solution. This is Elad trying to position himself for the upcoming election. This is an election campaign. Nothing more. https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates Elon, just save your next typing. You will immead scream that I am running an "illegal cyber defamation campaign" against you. Sure. whatever. Silvan On 4/26/20 4:22 PM, info at cowmedia.de wrote: Sorry Elad, i know ist Sunday and some members of this mailling list have more time as on a busy working day but are you really again (see the other topic) posting an idea in this list were we cannot do anything about this? You try to find or present solutions to problems that doesnt exist. While you think a lot on your ideas technically, please note that this is only 1/3 of the things you need to take care of. In this specific case you want to outsource the servers job of filtering SPAM out competely to the client. This is not how this was designed. You are thinking that email clients always have a UI or at least some bigger code behind it that is able to do a lot of stuff. There exist email clients in the world that have only <100 lines of code and are only text based (as email is from the ground up). We are completely the wrong audience group for your emails. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 19:20:05 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 17:20:05 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: , <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net>, Message-ID: Jetten, This is not up to you to decide. This is a membership discuss mailing list, I'm a member just like you are, please don't shut conversations and tell what we can or cannot talk about, Spam is a problem that is related to all Ripe LIR members including you. Respectfully, Elad ________________________________ From: members-discuss on behalf of Jetten Raymond Sent: Sunday, April 26, 2020 8:04 PM To: members-discuss at ripe.net ; Matthias Brumm Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem This list is NOT for technical related posts, it is for MEMBERSHIP related issues. Please move the discussion elsewhere. L?hetetty Outlook Mobilesta ________________________________ From: members-discuss on behalf of Matthias Brumm Sent: Sunday, April 26, 2020 7:50:23 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hi! To understand correctly. You want to enforce, that every subscribe operation / e-mail client operation (get new email from server) in the world will make a bidirectional communication with a central server? Do you have an ellaborated guess, how much computing power that would need? Matthias Am 26.04.20 um 18:05 schrieb Elad Cohen: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family -------------- next part -------------- An HTML attachment was scrubbed... URL: From href at fastmail.net Sun Apr 26 19:23:05 2020 From: href at fastmail.net (Jordan Bracco) Date: Sun, 26 Apr 2020 19:23:05 +0200 Subject: [members-discuss] =?utf-8?q?Technical_Solution_to_resolve_the_gl?= =?utf-8?q?obal_=22Email_Spam=22_problem?= In-Reply-To: References: Message-ID: <2fad3198-4fcc-4783-98ed-cbb2cc0a30de@www.fastmail.com> Dear Elad, Unrelated to the spam proposal-- but have you found a technical solution to avoid malicious third parties to hijack assigned IP space (for example, if I remember that there was some IP space from Cape Town city that got hijacked). What are you thoughts on this, and your technical solution to it ? On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: > Hello Everyone, > > I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). > > Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". > > > The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: > https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation > > > > The Implementation: > > There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. > > Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). > > After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). > > In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. > > The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). > > The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). > > The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). > > The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. > > > > The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): > > - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. > > - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. > > - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). > > - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). > > - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. > > - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. > > - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: > > - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. > > - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. > > > > > Whitelist Handshake: > > - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. > > - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc > > - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). > > > Notification of spam emails: > > - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). > > > > Email Spoofing: > > - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. > > - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. > > - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. > > - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. > > > > Security Aspects: > > - All stored data in NoSpam.org Backend infrastructure is hashed. > > - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. > > - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. > > - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). > > - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. > > > To make it short: > > - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). > > - Any email message from an email address or domain in whitelist - will reach the inbox. > > - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. > > - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. > > - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. > > - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. > > > > Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. > > > Respectfully, > Elad > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias at brumm.net Sun Apr 26 19:27:46 2020 From: matthias at brumm.net (Matthias Brumm) Date: Sun, 26 Apr 2020 19:27:46 +0200 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> Message-ID: <8b747a3e-3b93-9c23-4003-1e9fed67a3ad@brumm.net> Hi! Maybe, but no one here is in the position to make such a project work instantly. To get it rolling, this may be easier than IPv4+. Present a working proof-of-concept with nospan.org and a Thunderbird-Plug-In. Then try to get the E-Mail-Clients on board. As long as the nospam.org servers are scalable, you can grow very fast. Matthias Am 26.04.20 um 19:20 schrieb Elad Cohen: > Jetten, > > This is not up to you to decide. > > This is a membership discuss mailing list, I'm a member just like you > are, please don't shut conversations and tell what we can or cannot > talk about, Spam is a problem that is related to all Ripe LIR members > including you. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* members-discuss on behalf > of Jetten Raymond > *Sent:* Sunday, April 26, 2020 8:04 PM > *To:* members-discuss at ripe.net ; Matthias > Brumm > *Subject:* Re: [members-discuss] Technical Solution to resolve the > global "Email Spam" problem > This list is NOT for technical related posts, it is for MEMBERSHIP > related issues. Please move the discussion elsewhere. > > L?hetetty Outlook Mobilesta > > ------------------------------------------------------------------------ > *From:* members-discuss on behalf > of Matthias Brumm > *Sent:* Sunday, April 26, 2020 7:50:23 PM > *To:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] Technical Solution to resolve the > global "Email Spam" problem > > Hi! > > > To understand correctly. You want to enforce, that every subscribe > operation / e-mail client operation (get new email from server) in the > world will make a bidirectional communication with a central server? > Do you have an ellaborated guess, how much computing power that would > need? > > > Matthias > > > Am 26.04.20 um 18:05 schrieb Elad Cohen: >> Hello Everyone, >> >> I want to share with you my technical solution to resolve the global >> world "Email Spam" problem and in addition it will also resolve the >> spreading of illegal links (phishing/malware/etc , once the sites are >> known) through electronic mail and will stop email spoofing (that >> part using current technologies). >> >> Email spam problem was not being able to be defeated since the >> beginning of electronic mail, as long as email spam will be >> profitable to email spammers - it will exist, email spam caused the >> illegal anonymous organization "The Spamhaus Project" to exist, "The >> Spamhaus Project" is hurting and damaging many businesses worldwide >> in their way to fight email spam, "The Spamhaus Project" is an >> illegal anonymous organization according to the following >> presentation that they wrote on themselves, they are violating laws >> in their way to fight email spam and still they don't win in the >> battle against email spam. "The Spamhaus Project" is keeping their >> anonymity because they are afriad of justified lawsuits due to their >> criminal actions in their way to fight email spam. The following >> technical solution will resolve the world email spam problem without >> to hurt and to damage many businesses worldwide that have nothing to >> do with email spam like "The Spamhaus Project" does, the following >> implementation can remove the need for an illegal anonymous >> organization such as "The Spamhaus Project". >> >> >> The presentation that the illegal anonymous organization "The >> Spamhaus Project" wrote on themselves: >> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >> >> >> >> The Implementation: >> >> There will be a site (lets call it NoSpam.org) - the site will be >> owned by the 5 RIRs, the site will use bgp anycast and will be >> deployed in each of the 5 RIRs (the site will also be able to be >> deployed by the ccTLD registries in each country), the site in all >> the locations will be synced automatically. >> >> Each domain owner will be able to register at the site (an email >> message will be sent to the domain owner email address in the domain >> name WHOIS details in order to verify that the domain owner is the >> one registering). >> >> After being logged in, a domain owner will be able to add his email >> addresses (of the specific domain name) that will be used to send >> newsletters / mailing lists / one-to-many email messages, lets call >> these kind of email addresses as 'mailing list' email addresses. The >> domain owner will not be able to see the list of 'mailing list' email >> addresses that he added - because when he added each 'mailing list' >> email address it will be saved with hash in the NoSpam.org backend >> infrastructure (due to privacy and security reasons) - hence only if >> the domain owner will manually type the 'mailing list' email address >> he will be able to enter it in order to manage it (to see the total >> number of subscribers email addresses, to see the subscribers email >> addresses but only with their hashes due to security and privacy >> reasons, to remove a subscriber from the list, to add a sub-user with >> permissions to manage that specific 'mailing list' email address). >> >> In his site, the domain owner will be able to integrate an iframe >> from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a >> subscriber registration form to his specific 'mailing list' email >> address, the subscriber will receive an email message with a link to >> confirm his subscription. >> >> The domain owner will need to create a callback file in his website, >> for example in the path: "/nospam-notification-callback" >> (http://example.com/nospam-notification-callback) - that url will >> receive encrypted post notifications (encryption key will be provided >> by the domain owner in his NoSpam.org logged in account) from >> NoSpam.org regarding any new end-user that will subscribe or that >> will unsubscribe from a 'mailing address' email address which is >> related to the domain of the domain owner (unsubscribe functionality >> by the user later below). >> >> The subscriber email address and that 'mailing list' email address >> (that was subscribed to) will be sent by NoSpam.org to >> "/nospam-notification-callback" not in the hashed format but in >> cleartext (so the domain owner will be able to save it in his system >> for future email messages from the specific 'mailing list' email >> address to the specific subscriber email address). >> >> The domain owner will also have an API to NoSpam.org backend >> infrastructure in order to remove a specific subscriber email address >> from a specific 'mailing list' email address (the domains owner will >> send the values through the API - hashed). >> >> The domain owner will also provide a web interface in his site for >> the end-user to remove himself from the specific 'mailing list' email >> address. >> >> >> >> The above is the backend implementation (no upgrade is needed to any >> email server in the internet), the following is the upgrade that will >> needed for any email client (that upgrade is not mandatory, without >> the following upgrade the email client will work exactly as it is now >> without the added no-spam features, electronic mail will not break if >> some email users will upgrade their email clients and some will not): >> >> - There will not be 'mark as spam' button, that kind of functionality >> will stop to exist because spam is not a boolean value, 'spam' to one >> person is valuable to another 'person', specially when the internet >> is global and different people from different countries will consider >> spam content differently. One user can consider an email message as >> spam and another user can consider the same message as not spam, >> 'Spam' is subjective and any kind of 'mark as spam' functionality is >> useless in the battle against email spam. >> >> - There will be blacklists and whitelists (just like there are now, >> but they will be more prominent): blacklist email addresses , >> blacklist domains , whitelist email addresses , whitelist domains. >> >> - The end-user should be able to easily enter each email message to >> whitelist or to blacklist (meaning the 'from' email address of the >> email message), and will be able to search in the 'Spam' folder >> easily for an email address (these features can exist today, but they >> should be given more visibility, so end-users will use them more). >> >> - The end-user will be able to import/export his whitelists and >> blacklists using an xml format to any other upgraded email client, >> the blacklists and whitelists will be local (end-user will be able to >> pass the local whitelists and blacklists to another email client of >> his with the click of a button in the upgraded email client - the >> upgraded email client will just send them to itself - without to >> download them from the email server so the end-user will be able to >> download it with another upgraded email client - or the end-user will >> be able to send the whitelists and blacklists to another email >> address of him, the usage will not be like sending regular email >> message with attachments - the upgraded email clients will take care >> to sending and receiving of the blacklists and whitelits - in the >> background, these are custom formatted email messages that the two >> upgraded email clients will know how to act upon them). >> >> - The email client will be able to display with GUI with buttons any >> 'mailing-list registration confirmation email' in a specific section >> related to registration to new 'mailing list' email addresses for the >> end-user to choose with buttons if he accept or refuse to register to >> a specific 'mailing list' email address. >> >> - For any email message that was received: in case a received 'from' >> email address was found in the whitelist email addresses or in the >> whitelist domains - then it will be moved to the 'Inbox' folder, in >> case the 'from' email address of the email message was found in the >> blacklist email addresses or in the blacklist domains - then the >> email message will be moved to the 'Trash' folder. >> >> - In case the 'from' email address or domain was not found in the >> whitelists and in the blacklists, then the upgraded email client will >> send the 'from' email address and the 'from' domain and the current >> user email address and the external links that exist in the email >> message (but all of these data will be sent in a hashed way, and not >> in cleartext) with a query to NoSpam.org backend infrastructure, >> NoSpam.org will perform the following algorithem after it: >> >> - If the hashed 'from' domain (or any other 'hashed' domain from the >> external links) exist in a list of criminals hashed domains (of >> phishing/malware/viruses/etc) then NoSpam.org will respond to the >> email client to delete the email message, otherwise the hashed 'from' >> email address will be checked against a list of hashed 'mailing list' >> email addresses - if found then the sender is a 'mailing list' email >> address and there will be a check by NoSpam.org backend >> infrastructure if the hashed 'receiver' email address is a subscriber >> of that specific 'mailing list' email address , if the hashed >> 'receiver' was found then NoSpam.org will send a response to the >> email client that the email message can be displayed in the 'Inbox' >> folder and in the response NoSpam.org will also include an >> unsubscribe key - the email client will be able to display an >> unsubscribe button to the email client and if clicked the email >> client will send an https request to NoSpam.org with the specific >> unsubscribe key, NoSpam.org backend infrastructure will remove the >> end-user email address from the 'mailing list' email address and will >> notify the domain owner at the domain owner callback url >> "/nospam-notification-callback" that the specific user unsubscribed. >> In case the hashed 'receiver' wasn't found then NoSpam.org will >> respond to the email client to delete the email message and >> NoSpam.org will also notify the callback url of the related domain >> owner that he shouldn't send email messages from the specific >> 'mailing ?list' email address to the specific subscriber email address. >> >> - In case when NoSpam.org backend infrastructure searched the hashed >> 'from' email address and it wasn't found in the list of all hashed >> 'mailing list' email addresses, it mean that the email address was >> sent from a 'personal' email address and NoSpam.org backend >> infrastructure will notify the email client that the email message is >> from a 'personal' email address - the email client in that stage will >> need to decide if to move the email message to the 'Inbox' folder or >> to the 'Spam' folder based on the following - the email client will >> check if the email message include links/images/plain-url's - and if >> yes then the email message will be moved to the 'Spam' folder, >> otherwise it will be moved to the 'Inbox' folder. >> >> >> >> >> Whitelist Handshake: >> >> - In order to facilitate the adding of new email address to the local >> whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist >> Handshake' is a GUI representation in two email clients regarding >> background email messages between them (that the two end-users don't >> see), "end-user A" with a click of a button will be able to send 'add >> me to whitelist' request to "end-user B" which will be able to accept >> or deny and if accepted then "end-user B" will be able to >> automatically send the same "add me to whitelist" request to >> "end-user A" , all of this communication will be done behind the >> scenes, these special email messages will not be visible to the >> end-users, end-users will see popups with GUI that email address X is >> asking to be added to whitelist. In order for spammers not to abuse >> this option - the email client will keep only one 'whitelist request' >> from each requester email address (there will be a 'whitelist >> requests' section in the upgraded email client). A repeated >> 'whitelist request' that came from a specific email address can never >> be raised in the list (unless the end-user will specifically search >> for it) even when the sender will send more and more 'add me to >> whitelist' requests - no priority will given to them, and once an >> end-user refused an 'add me to whitelist' request - no new 'add me to >> whitelist' request will be shown from the specific sender email >> address in the specific email client. >> >> - There can be a case that an upgraded email client will send 'add me >> to whitelist' request to a not-upgraded email client and then the >> receiver will see the request as it is - as an email message in the >> inbox folder - due to it the content of that message will be in the >> language of the domain TLD of the receiver email address and the >> content in the email message will explain what is NoSpam.org and how >> to upgrade the email client and supported upgraded email clients, etc >> >> - In the 'whitelist requests section' in the upgraded email client - >> the whitelist requests will appear in a list - there should be >> preference so some requests will appear upper and other lower (so >> requests from spammers will appear lower) - whitelist requests from >> email addresses of domains which are older (according to their WHOIS >> details) will appear upper than whitelist requests from email >> addresses of domains which are newer. Whitelist requests from a list >> of a more-trusted-domains (domains of known webmails service, >> universities, governments, etc) will have preference over other >> domains, specific TLDs that not anyone can purchase will also have >> preference over other TLDs that anyone can purchase (upgraded email >> clients will retrieve the list of trusted TLD's and Domains each day >> from NoSpam.org backend infrastructure). >> >> >> Notification of spam emails: >> >> - An additional feature in the upgraded email client is that whenever >> an email message will reach the 'Spam' folder - the email client will >> send in the background a known-format email message to the sender and >> will notify him about it, if the sender is using an upgraded email >> client then it will be able to automatically send a 'add me to >> whitelist' request to the receiver in the background (once an email >> address is whitelisted - all the email messages from it will move >> from 'Spam' to 'Inbox'). >> >> >> >> Email Spoofing: >> >> - In an upgraded email client, email messages from 'personal' email >> addresses cannot arrive from email relay server, in case it happen >> the message will be deleted and the email client will send an >> automatic email message in the background to the sender with the text >> (in the language of the sender domain TLD) that email messages from >> 'email relay servers' cannot be received from him. >> >> - In an upgraded email client, email messages from 'mailing list' >> email addresses can arrive from email relay servers - but they must >> be encrypted with DKIM. >> >> - In an upgraded email client, the email client should check the SPF >> txt dns record of the sender domain, and will drop the email message >> if it is a spoofed email message. >> >> - DNS servers developers will need to make the SPF txt dns record to >> be a mandatory field for every domain, in order for email spoofing to >> be annihilated. >> >> >> >> Security Aspects: >> >> - All stored data in NoSpam.org Backend infrastructure is hashed. >> >> - The criminals domains list in NoSpam.org Backend Infrastructure >> will be managed only by regulated supervised Law Enforcement Agency >> (for example: Interpol) and not by an internet organization such as >> the RIRs or ccTLD registries. >> >> - Domains owners will have 'forgot password' functionality to their >> NoSpam.org account, the password reset link will be sent to the email >> address of the owner of the domain according to the domain WHOIS details. >> >> - Communication between email clients to NoSpam.org backend >> infrastructure will be over https, there will only be an handshake >> process in the beginning over electronic mail between email client >> and NoSpam.org backend infrastructure - the email client will send an >> email message with a chosen key to an email address of @nospam.org >> (that key will be used in further communication between the email >> client and the NoSpam.org backend infrastructure over https, it will >> be used for NoSpam.org backend infrastructure to identify the >> specific email address over https, so anyone will not be able to >> query NoSpam.org backend infrastructure to know which hashed email >> address belongs to which hashed 'mailing list' email address, besides >> the email client user with the right key to query NoSpam.org Backend >> infrastructure only on himself). >> >> - Any email client will download once per day 'spam-rules' file from >> NoSpam.org backend infrastructure, 'spam-rules' file will be an xml >> formatted file that include rules of when to move an email message >> that was received from 'personal' email address which is not >> whitelisted to the 'Spam' folder (for example, when email have at >> least 1/2/3 links, when email format is rich text or html and not >> plaintext, etc), in case future adjustments will be needed to win the >> battle against email spam - email clients will not need to be >> upgraded, the new 'spam-rules' will be updated in this daily file. >> >> >> To make it short: >> >> - Any email message from a subscribed mailing list / newsletter / etc >> - will reach to the inbox (that kind of email messages can contain >> any kind of content without any restrictions, because the user >> subscribed to it and the user can unsubscribe from it at anytime). >> >> - Any email message from an email address or domain in whitelist - >> will reach the inbox. >> >> - Whitelist Handshake process is easy to use and being implemented >> with clicks of a button, nothing to type. >> >> - In case an email message will the 'Spam' folder - an automatic >> email message will be sent from the receiver to sender and sender can >> automatically ask to be added to the receiver's whitelist. >> >> - Any email message without links/images/plain-url's (plain email >> messages, like electronic email was) - will reach the inbox. >> >> - Any other email will reach the 'Spam' folder - if needed the user >> will be able to easily whitelist the email message in the 'Spam' folder. >> >> >> >> Spammers need links in their email messages for monetization, above >> solution blocks it and also block criminal domains links in email >> message and implement email spoofing blocking at client-side. We will >> all stop to receive more than 100 spam email messages per day with >> the above solution. >> >> >> Respectfully, >> Elad >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net > -- > Unser Familien-Blog:https://brumm.family -- Unser Familien-Blog: https://brumm.family -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 19:31:37 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 17:31:37 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <8b747a3e-3b93-9c23-4003-1e9fed67a3ad@brumm.net> References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> , <8b747a3e-3b93-9c23-4003-1e9fed67a3ad@brumm.net> Message-ID: Hello, Ripe have 30 millions euros of expenses each year that are hidden and now shown to where exactly they are paid, instead of that corruption - a small part of the money can be used also for the deployment of IPv4+ and also for NoSpam.org and also for the next solution that I will present regarding how to dramatically lower ddos attacks, a simple and elegant solution that will help each and every ASN in the world. Respectfully, Elad ________________________________ From: Matthias Brumm Sent: Sunday, April 26, 2020 8:27 PM To: Elad Cohen ; Jetten Raymond ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hi! Maybe, but no one here is in the position to make such a project work instantly. To get it rolling, this may be easier than IPv4+. Present a working proof-of-concept with nospan.org and a Thunderbird-Plug-In. Then try to get the E-Mail-Clients on board. As long as the nospam.org servers are scalable, you can grow very fast. Matthias Am 26.04.20 um 19:20 schrieb Elad Cohen: Jetten, This is not up to you to decide. This is a membership discuss mailing list, I'm a member just like you are, please don't shut conversations and tell what we can or cannot talk about, Spam is a problem that is related to all Ripe LIR members including you. Respectfully, Elad ________________________________ From: members-discuss on behalf of Jetten Raymond Sent: Sunday, April 26, 2020 8:04 PM To: members-discuss at ripe.net ; Matthias Brumm Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem This list is NOT for technical related posts, it is for MEMBERSHIP related issues. Please move the discussion elsewhere. L?hetetty Outlook Mobilesta ________________________________ From: members-discuss on behalf of Matthias Brumm Sent: Sunday, April 26, 2020 7:50:23 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hi! To understand correctly. You want to enforce, that every subscribe operation / e-mail client operation (get new email from server) in the world will make a bidirectional communication with a central server? Do you have an ellaborated guess, how much computing power that would need? Matthias Am 26.04.20 um 18:05 schrieb Elad Cohen: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family -- Unser Familien-Blog: https://brumm.family -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 19:18:41 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 17:18:41 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net>, Message-ID: LOL No, actually, NoSpam.org will be able to finance itself by providing delivery service to all the 'mailing list' email addresses with their newsletters. All the Income will go to the 5 RIR's and to the ccTLD registries for them to provide better services to their members. Respectfully, Elad ________________________________ From: members-discuss on behalf of Simon Lockhart Sent: Sunday, April 26, 2020 8:04 PM To: Matthias Brumm Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem On 26 Apr 2020, at 17:50, Matthias Brumm > wrote: Do you have an ellaborated guess, how much computing power that would need? The billions of dollars/euros that will be generated from the creation of IPv4+ will fund the massive server infrastructure. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From nevin at arcustech.com Sun Apr 26 19:34:29 2020 From: nevin at arcustech.com (Nevin Lyne) Date: Sun, 26 Apr 2020 12:34:29 -0500 Subject: [members-discuss] =?utf-8?q?=5BSPAM=5D_Technical_Solution_to_res?= =?utf-8?q?olve_the_global_=22Email_Spam=22_problem?= In-Reply-To: References: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online> Message-ID: <6e88907c-5fc9-48d2-986d-d3a688ba03f0@www.fastmail.com> Elad, Please stop this. It is very clear here: https://www.ripe.net/participate/member-support/membership-mailing-lists what this mailing lists purpose is: "Purpose To enable RIPE NCC members to discuss membership-related issues that affect them and to facilitate members' input into RIPE NCC General Meetings and related matters." Your posts are not membership related issues in reference to RIPE itself. You are seem to believe that if its a technical issue related to the whole of the Internet, this is the place to discuss it. This is the 2nd subject line from you in two days I have had to tell my email client to delete now if it comes from this mailing list and contains your subject line, because to me, at this point, you are spamming this mailing list. IF you want your technical ideas to be heard and discussed, how about you go over to https://www.rfc-editor.org/ and learn what you need to do to draft an Internet RFC on the subjects, which is the only place you are going to get a) a global audience, and b) find out that your "easy" solutions even if they make it through the RFC process likely will never be fully implemented by enough people to have an impact anytime within the next 10 to 15 years. Thank you. -Nevin On Sun, Apr 26, 2020, at 12:12 PM, Elad Cohen wrote: > Hello Ben, > > Thank you very much. > > I don't believe that spamming will ever stop (if there is one thing > that we can count on that will never change is human nature - and sadly > people here believe that spammers will just stop spamming at some > point), if spam will be defeated by email then spamming will be done > with sms messages or by phone, currently electronic mail is the most > profitable so it is most abused, and the current approaches to this > problem are completely wrong - "The Spamhaus Project" are chasing after > their tail, shooting everywhere, and not resolving the problem for many > years. > > "I hope everyone has a good rest of the weekend." - Yes, I'm making sure of it. > > Everyone need to stay tuned because there is a new technical solution > for tomorrow (how to dramatically lower DDoS attacks, a beautiful one). > > Respectfully, > Elad > *From:* members-discuss on behalf of > Ben Fitzgerald-O'Connor > *Sent:* Sunday, April 26, 2020 7:52 PM > *To:* Silvan Gebhardt ; > members-discuss at ripe.net > *Subject:* Re: [members-discuss] [SPAM] Technical Solution to resolve > the global "Email Spam" problem > Hi All, > > > I generally lurk here but a small comment on this.. > > > Reading the thread, my humble opinion: > > > @Elad ? noting the comments, I think I do agree that email problems / > solutions might be better submitted as an RFC > (https://www.ietf.org/standards/rfcs/) .. Ripe is a LIR mainly tasked > with administering IP number resources. ? At the same time, I do love > your obvious passion for addressing problems and looking freshly at > possible solutions. Regarding the upcoming election ? I have just had a > look at the page with Candidate Biographies to judge a little how I > might vote ? at > https://www.ripe.net/participate/meetings/gm/meetings/may-2020/candidate-biographies .. and I can?t see you there, so would suggest please to submit / add a biography if this is not already in the works (and I hope all candidates do too). > > > NB ? be careful that if you do come up with a solution to fix spam once > and for all then beware that you also put a USD $10 Billion value on > your own head (this is the rough value annually of the anti-spam > industry!) (Comment partly in jest, partly from experience and > observation). > > > I hope everyone has a good rest of the weekend. > > > Regards > > Ben > > > *From:* members-discuss *On Behalf > Of *Silvan Gebhardt > *Sent:* 26 April 2020 17:33 > *To:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] [SPAM] Technical Solution to resolve > the global "Email Spam" problem > > > Hi Michael, > > > this is not about any technical solution. This is Elad trying to > position himself for the upcoming election. > > This is an election campaign. Nothing more. > > > https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates > > > Elon, just save your next typing. You will immead scream that I am > running an "illegal cyber defamation campaign" against you. Sure. > whatever. > > > > Silvan > > On 4/26/20 4:22 PM, info at cowmedia.de wrote: > > > Sorry Elad, > > > > i know ist Sunday and some members of this mailling list have more time as on a busy working day but are you really again (see the other topic) posting an idea in this list were we cannot do anything about this? > > > > You try to find or present solutions to problems that doesnt exist. While you think a lot on your ideas technically, please note that this is only 1/3 of the things you need to take care of. > > > In this specific case you want to outsource the servers job of filtering SPAM out competely to the client. This is not how this was designed. You are thinking that email clients always have a UI or at least some bigger code behind it that is able to do a lot of stuff. There exist email clients in the world that have only <100 lines of code and are only text based (as email is from the ground up). > > > > We are completely the wrong audience group for your emails. > > > > Michael > > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/nevin%40arcustech.com > From info at cowmedia.de Sun Apr 26 19:38:01 2020 From: info at cowmedia.de (info at cowmedia.de) Date: Sun, 26 Apr 2020 19:38:01 +0200 Subject: [members-discuss] [SPAM] Re: Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: , <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net>, Message-ID: <38ce01d61bf1$6ef38650$4cda92f0$@cowmedia.de> Hi Elad, > This is not up to you to decide. But also not for you. It is decided by RIPE NCC You can see the intended purpose of this liste here on this page: https://www.ripe.net/participate/mail/ripe-ncc-mailing-lists/members-discuss Please do all of us a favor and do not post your new idea for tomorrow here. Thx. Michael P.S.: As you can see in the title my mailserver is already able to mark your email as SPAM correctly even the traditional already existing filter mechanisms are used. Von: members-discuss Im Auftrag von Elad Cohen Gesendet: Sonntag, 26. April 2020 19:20 An: Jetten Raymond ; members-discuss at ripe.net; Matthias Brumm Betreff: [SPAM] Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Jetten, This is not up to you to decide. This is a membership discuss mailing list, I'm a member just like you are, please don't shut conversations and tell what we can or cannot talk about, Spam is a problem that is related to all Ripe LIR members including you. Respectfully, Elad _____ From: members-discuss > on behalf of Jetten Raymond > Sent: Sunday, April 26, 2020 8:04 PM To: members-discuss at ripe.net >; Matthias Brumm > Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem This list is NOT for technical related posts, it is for MEMBERSHIP related issues. Please move the discussion elsewhere. L?hetetty Outlook Mobilesta -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5533 bytes Desc: not available URL: From elad at netstyle.io Sun Apr 26 19:46:08 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 17:46:08 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <2fad3198-4fcc-4783-98ed-cbb2cc0a30de@www.fastmail.com> References: , <2fad3198-4fcc-4783-98ed-cbb2cc0a30de@www.fastmail.com> Message-ID: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. Respectfully, Elad ________________________________ From: members-discuss on behalf of Jordan Bracco Sent: Sunday, April 26, 2020 8:23 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Dear Elad, Unrelated to the spam proposal-- but have you found a technical solution to avoid malicious third parties to hijack assigned IP space (for example, if I remember that there was some IP space from Cape Town city that got hijacked). What are you thoughts on this, and your technical solution to it ? On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 19:58:34 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 17:58:34 +0000 Subject: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <6e88907c-5fc9-48d2-986d-d3a688ba03f0@www.fastmail.com> References: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online> , <6e88907c-5fc9-48d2-986d-d3a688ba03f0@www.fastmail.com> Message-ID: Nevin, You are clearly full of interests. "b) find out that your "easy" solutions even if they make it through the RFC process likely will never be fully implemented by enough people to have an impact anytime within the next 10 to 15 years." If you don't know how to resolve the internet problems that affects all of us you should not disturb people who are doing it. What I'm writing fits under "related matters." There are people in Ripe that are trying to shut me up including you and you will not succeed. Respectfully, Elad ________________________________ From: members-discuss on behalf of Nevin Lyne Sent: Sunday, April 26, 2020 8:34 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem Elad, Please stop this. It is very clear here: https://www.ripe.net/participate/member-support/membership-mailing-lists what this mailing lists purpose is: "Purpose To enable RIPE NCC members to discuss membership-related issues that affect them and to facilitate members' input into RIPE NCC General Meetings and related matters." Your posts are not membership related issues in reference to RIPE itself. You are seem to believe that if its a technical issue related to the whole of the Internet, this is the place to discuss it. This is the 2nd subject line from you in two days I have had to tell my email client to delete now if it comes from this mailing list and contains your subject line, because to me, at this point, you are spamming this mailing list. IF you want your technical ideas to be heard and discussed, how about you go over to https://www.rfc-editor.org/ and learn what you need to do to draft an Internet RFC on the subjects, which is the only place you are going to get a) a global audience, and b) find out that your "easy" solutions even if they make it through the RFC process likely will never be fully implemented by enough people to have an impact anytime within the next 10 to 15 years. Thank you. -Nevin On Sun, Apr 26, 2020, at 12:12 PM, Elad Cohen wrote: > Hello Ben, > > Thank you very much. > > I don't believe that spamming will ever stop (if there is one thing > that we can count on that will never change is human nature - and sadly > people here believe that spammers will just stop spamming at some > point), if spam will be defeated by email then spamming will be done > with sms messages or by phone, currently electronic mail is the most > profitable so it is most abused, and the current approaches to this > problem are completely wrong - "The Spamhaus Project" are chasing after > their tail, shooting everywhere, and not resolving the problem for many > years. > > "I hope everyone has a good rest of the weekend." - Yes, I'm making sure of it. > > Everyone need to stay tuned because there is a new technical solution > for tomorrow (how to dramatically lower DDoS attacks, a beautiful one). > > Respectfully, > Elad > *From:* members-discuss on behalf of > Ben Fitzgerald-O'Connor > *Sent:* Sunday, April 26, 2020 7:52 PM > *To:* Silvan Gebhardt ; > members-discuss at ripe.net > *Subject:* Re: [members-discuss] [SPAM] Technical Solution to resolve > the global "Email Spam" problem > Hi All, > > > I generally lurk here but a small comment on this.. > > > Reading the thread, my humble opinion: > > > @Elad ? noting the comments, I think I do agree that email problems / > solutions might be better submitted as an RFC > (https://www.ietf.org/standards/rfcs/) .. Ripe is a LIR mainly tasked > with administering IP number resources. ? At the same time, I do love > your obvious passion for addressing problems and looking freshly at > possible solutions. Regarding the upcoming election ? I have just had a > look at the page with Candidate Biographies to judge a little how I > might vote ? at > https://www.ripe.net/participate/meetings/gm/meetings/may-2020/candidate-biographies .. and I can?t see you there, so would suggest please to submit / add a biography if this is not already in the works (and I hope all candidates do too). > > > NB ? be careful that if you do come up with a solution to fix spam once > and for all then beware that you also put a USD $10 Billion value on > your own head (this is the rough value annually of the anti-spam > industry!) (Comment partly in jest, partly from experience and > observation). > > > I hope everyone has a good rest of the weekend. > > > Regards > > Ben > > > *From:* members-discuss *On Behalf > Of *Silvan Gebhardt > *Sent:* 26 April 2020 17:33 > *To:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] [SPAM] Technical Solution to resolve > the global "Email Spam" problem > > > Hi Michael, > > > this is not about any technical solution. This is Elad trying to > position himself for the upcoming election. > > This is an election campaign. Nothing more. > > > https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates > > > Elon, just save your next typing. You will immead scream that I am > running an "illegal cyber defamation campaign" against you. Sure. > whatever. > > > > Silvan > > On 4/26/20 4:22 PM, info at cowmedia.de wrote: > > > Sorry Elad, > > > > i know ist Sunday and some members of this mailling list have more time as on a busy working day but are you really again (see the other topic) posting an idea in this list were we cannot do anything about this? > > > > You try to find or present solutions to problems that doesnt exist. While you think a lot on your ideas technically, please note that this is only 1/3 of the things you need to take care of. > > > In this specific case you want to outsource the servers job of filtering SPAM out competely to the client. This is not how this was designed. You are thinking that email clients always have a UI or at least some bigger code behind it that is able to do a lot of stuff. There exist email clients in the world that have only <100 lines of code and are only text based (as email is from the ground up). > > > > We are completely the wrong audience group for your emails. > > > > Michael > > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/nevin%40arcustech.com > _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/elad%40netstyle.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 20:00:46 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 18:00:46 +0000 Subject: [members-discuss] [SPAM] Re: Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <38ce01d61bf1$6ef38650$4cda92f0$@cowmedia.de> References: , <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net>, , <38ce01d61bf1$6ef38650$4cda92f0$@cowmedia.de> Message-ID: Michael, Why are you spamming the list ? What I'm writing its under the intended purpose, you decided that it is not, if you are not interested to read my email then simply in your email client block it. Respectfully, Elad ________________________________ From: members-discuss on behalf of info at cowmedia.de Sent: Sunday, April 26, 2020 8:38 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Re: Technical Solution to resolve the global "Email Spam" problem Hi Elad, > This is not up to you to decide. But also not for you. It is decided by RIPE NCC You can see the intended purpose of this liste here on this page: https://www.ripe.net/participate/mail/ripe-ncc-mailing-lists/members-discuss Please do all of us a favor and do not post your new idea for tomorrow here. Thx. Michael P.S.: As you can see in the title my mailserver is already able to mark your email as SPAM correctly even the traditional already existing filter mechanisms are used. Von: members-discuss Im Auftrag von Elad Cohen Gesendet: Sonntag, 26. April 2020 19:20 An: Jetten Raymond ; members-discuss at ripe.net; Matthias Brumm Betreff: [SPAM] Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Jetten, This is not up to you to decide. This is a membership discuss mailing list, I'm a member just like you are, please don't shut conversations and tell what we can or cannot talk about, Spam is a problem that is related to all Ripe LIR members including you. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Jetten Raymond > Sent: Sunday, April 26, 2020 8:04 PM To: members-discuss at ripe.net >; Matthias Brumm > Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem This list is NOT for technical related posts, it is for MEMBERSHIP related issues. Please move the discussion elsewhere. L?hetetty Outlook Mobilesta -------------- next part -------------- An HTML attachment was scrubbed... URL: From nevin at arcustech.com Sun Apr 26 20:04:35 2020 From: nevin at arcustech.com (Nevin Lyne) Date: Sun, 26 Apr 2020 13:04:35 -0500 Subject: [members-discuss] =?utf-8?q?=5BSPAM=5D_Technical_Solution_to_res?= =?utf-8?q?olve_the_global_=22Email_Spam=22_problem?= In-Reply-To: References: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online> <6e88907c-5fc9-48d2-986d-d3a688ba03f0@www.fastmail.com> Message-ID: <17e3fdba-b163-4b25-b035-d8f11c16ac79@www.fastmail.com> Elad, No, I am not full of interest, what I have is a full mailbox of crap from you that has NOTHING to do with my membership IN RIPE. If you have issues with your Fees, or how you claim RIPE is not spending $30 million Euros properly, etc. Those are issues related to your membership in RIPE, and would be worth discussion on this list. I also am simply going to setup a more advanced filter that finds your name/email address anywhere in the incoming message and deletes it, but allows me to keep my normal membership in this mailing list intact. Have a nice day. -Nevin On Sun, Apr 26, 2020, at 12:58 PM, Elad Cohen wrote: > Nevin, > > You are clearly full of interests. > > "b) find out that your "easy" solutions even if they make it through > the RFC process likely will never be fully implemented by enough people > to have an impact anytime within the next 10 to 15 years." > > If you don't know how to resolve the internet problems that affects > all of us you should not disturb people who are doing it. > > What I'm writing fits under "related matters." > > There are people in Ripe that are trying to shut me up including you > and you will not succeed. > > Respectfully, > Elad > *From:* members-discuss on behalf of > Nevin Lyne > *Sent:* Sunday, April 26, 2020 8:34 PM > *To:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] [SPAM] Technical Solution to resolve > the global "Email Spam" problem > Elad, > > Please stop this. It is very clear here: > https://www.ripe.net/participate/member-support/membership-mailing-lists what this mailing lists purpose is: > > "Purpose > > To enable RIPE NCC members to discuss membership-related issues that > affect them and to facilitate members' input into RIPE NCC General > Meetings and related matters." > > Your posts are not membership related issues in reference to RIPE > itself. You are seem to believe that if its a technical issue related > to the whole of the Internet, this is the place to discuss it. > > This is the 2nd subject line from you in two days I have had to tell > my email client to delete now if it comes from this mailing list and > contains your subject line, because to me, at this point, you are > spamming this mailing list. > > IF you want your technical ideas to be heard and discussed, how about > you go over to https://www.rfc-editor.org/ and learn what you need to > do to draft an Internet RFC on the subjects, which is the only place > you are going to get a) a global audience, and b) find out that your > "easy" solutions even if they make it through the RFC process likely > will never be fully implemented by enough people to have an impact > anytime within the next 10 to 15 years. > > Thank you. > > -Nevin > > On Sun, Apr 26, 2020, at 12:12 PM, Elad Cohen wrote: > > Hello Ben, > > > > Thank you very much. > > > > I don't believe that spamming will ever stop (if there is one thing > > that we can count on that will never change is human nature - and > sadly > > people here believe that spammers will just stop spamming at some > > point), if spam will be defeated by email then spamming will be done > > with sms messages or by phone, currently electronic mail is the most > > profitable so it is most abused, and the current approaches to this > > problem are completely wrong - "The Spamhaus Project" are chasing > after > > their tail, shooting everywhere, and not resolving the problem for > many > > years. > > > > "I hope everyone has a good rest of the weekend." - Yes, I'm making > sure of it. > > > > Everyone need to stay tuned because there is a new technical > solution > > for tomorrow (how to dramatically lower DDoS attacks, a beautiful > one). > > > > Respectfully, > > Elad > > *From:* members-discuss on behalf > of > > Ben Fitzgerald-O'Connor > > *Sent:* Sunday, April 26, 2020 7:52 PM > > *To:* Silvan Gebhardt ; > > members-discuss at ripe.net > > *Subject:* Re: [members-discuss] [SPAM] Technical Solution to > resolve > > the global "Email Spam" problem > > Hi All, > > > > > > I generally lurk here but a small comment on this.. > > > > > > Reading the thread, my humble opinion: > > > > > > @Elad ? noting the comments, I think I do agree that email problems > / > > solutions might be better submitted as an RFC > > (https://www.ietf.org/standards/rfcs/) .. Ripe is a LIR mainly > tasked > > with administering IP number resources. ? At the same time, I do > love > > your obvious passion for addressing problems and looking freshly at > > possible solutions. Regarding the upcoming election ? I have just > had a > > look at the page with Candidate Biographies to judge a little how I > > might vote ? at > > > https://www.ripe.net/participate/meetings/gm/meetings/may-2020/candidate-biographies .. and I can?t see you there, so would suggest please to submit / add a biography if this is not already in the works (and I hope all candidates do too). > > > > > > NB ? be careful that if you do come up with a solution to fix spam > once > > and for all then beware that you also put a USD $10 Billion value on > > your own head (this is the rough value annually of the anti-spam > > industry!) (Comment partly in jest, partly from experience and > > observation). > > > > > > I hope everyone has a good rest of the weekend. > > > > > > Regards > > > > Ben > > > > > > *From:* members-discuss *On > Behalf > > Of *Silvan Gebhardt > > *Sent:* 26 April 2020 17:33 > > *To:* members-discuss at ripe.net > > *Subject:* Re: [members-discuss] [SPAM] Technical Solution to > resolve > > the global "Email Spam" problem > > > > > > Hi Michael, > > > > > > this is not about any technical solution. This is Elad trying to > > position himself for the upcoming election. > > > > This is an election campaign. Nothing more. > > > > > > > https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates > > > > > > Elon, just save your next typing. You will immead scream that I am > > running an "illegal cyber defamation campaign" against you. Sure. > > whatever. > > > > > > > > Silvan > > > > On 4/26/20 4:22 PM, info at cowmedia.de wrote: > > > > > Sorry Elad, > > > > > > > i know ist Sunday and some members of this mailling list have more > time as on a busy working day but are you really again (see the other > topic) posting an idea in this list were we cannot do anything about > this? > > > > > > > You try to find or present solutions to problems that doesnt > exist. While you think a lot on your ideas technically, please note > that this is only 1/3 of the things you need to take care of. > > > > > In this specific case you want to outsource the servers job of > filtering SPAM out competely to the client. This is not how this was > designed. You are thinking that email clients always have a UI or at > least some bigger code behind it that is able to do a lot of stuff. > There exist email clients in the world that have only <100 lines of > code and are only text based (as email is from the ground up). > > > > > > > We are completely the wrong audience group for your emails. > > > > > > > Michael > > > > > > > > _______________________________________________ > > members-discuss mailing list > > members-discuss at ripe.net > > https://lists.ripe.net/mailman/listinfo/members-discuss > > Unsubscribe: > > > https://lists.ripe.net/mailman/options/members-discuss/nevin%40arcustech.com > > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/elad%40netstyle.io -- -- Nevin Lyne -- Founder and Director of Technology -- Arcustech, LLC - https://www.arcustech.com/ From aleksi at magnacapax.fi Sun Apr 26 20:07:34 2020 From: aleksi at magnacapax.fi (Aleksi) Date: Sun, 26 Apr 2020 21:07:34 +0300 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> Message-ID: <028f0ff6-7c85-9c04-a862-88ecbc3cfc95@magnacapax.fi> and that will fund a Orwellian mass surveillance on the go as well as a "nice" byproduct On 4/26/20 8:04 PM, Simon Lockhart wrote: > >> On 26 Apr 2020, at 17:50, Matthias Brumm > > wrote: >> ?Do you have an ellaborated guess, how much computing power that >> would need? > > The billions of dollars/euros that will be generated from the creation > of IPv4+ will fund the massive server infrastructure. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 20:08:38 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 18:08:38 +0000 Subject: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <17e3fdba-b163-4b25-b035-d8f11c16ac79@www.fastmail.com> References: <36e501d61be6$e7dc2280$b7946780$@cowmedia.de> <36c27432-b261-d054-6ff6-160cc7c88d0e@unavailable.online> <6e88907c-5fc9-48d2-986d-d3a688ba03f0@www.fastmail.com> , <17e3fdba-b163-4b25-b035-d8f11c16ac79@www.fastmail.com> Message-ID: Nevin, Ripe board not interested to provide detailed list of expenses with providers names in order for us all to know where the the LIRs money of 30 million euros per year is flowing - have to do with your membership in Ripe. Respectfully, Elad ________________________________ From: Nevin Lyne Sent: Sunday, April 26, 2020 9:04 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] [SPAM] Technical Solution to resolve the global "Email Spam" problem Elad, No, I am not full of interest, what I have is a full mailbox of crap from you that has NOTHING to do with my membership IN RIPE. If you have issues with your Fees, or how you claim RIPE is not spending $30 million Euros properly, etc. Those are issues related to your membership in RIPE, and would be worth discussion on this list. I also am simply going to setup a more advanced filter that finds your name/email address anywhere in the incoming message and deletes it, but allows me to keep my normal membership in this mailing list intact. Have a nice day. -Nevin On Sun, Apr 26, 2020, at 12:58 PM, Elad Cohen wrote: > Nevin, > > You are clearly full of interests. > > "b) find out that your "easy" solutions even if they make it through > the RFC process likely will never be fully implemented by enough people > to have an impact anytime within the next 10 to 15 years." > > If you don't know how to resolve the internet problems that affects > all of us you should not disturb people who are doing it. > > What I'm writing fits under "related matters." > > There are people in Ripe that are trying to shut me up including you > and you will not succeed. > > Respectfully, > Elad > *From:* members-discuss on behalf of > Nevin Lyne > *Sent:* Sunday, April 26, 2020 8:34 PM > *To:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] [SPAM] Technical Solution to resolve > the global "Email Spam" problem > Elad, > > Please stop this. It is very clear here: > https://www.ripe.net/participate/member-support/membership-mailing-lists what this mailing lists purpose is: > > "Purpose > > To enable RIPE NCC members to discuss membership-related issues that > affect them and to facilitate members' input into RIPE NCC General > Meetings and related matters." > > Your posts are not membership related issues in reference to RIPE > itself. You are seem to believe that if its a technical issue related > to the whole of the Internet, this is the place to discuss it. > > This is the 2nd subject line from you in two days I have had to tell > my email client to delete now if it comes from this mailing list and > contains your subject line, because to me, at this point, you are > spamming this mailing list. > > IF you want your technical ideas to be heard and discussed, how about > you go over to https://www.rfc-editor.org/ and learn what you need to > do to draft an Internet RFC on the subjects, which is the only place > you are going to get a) a global audience, and b) find out that your > "easy" solutions even if they make it through the RFC process likely > will never be fully implemented by enough people to have an impact > anytime within the next 10 to 15 years. > > Thank you. > > -Nevin > > On Sun, Apr 26, 2020, at 12:12 PM, Elad Cohen wrote: > > Hello Ben, > > > > Thank you very much. > > > > I don't believe that spamming will ever stop (if there is one thing > > that we can count on that will never change is human nature - and > sadly > > people here believe that spammers will just stop spamming at some > > point), if spam will be defeated by email then spamming will be done > > with sms messages or by phone, currently electronic mail is the most > > profitable so it is most abused, and the current approaches to this > > problem are completely wrong - "The Spamhaus Project" are chasing > after > > their tail, shooting everywhere, and not resolving the problem for > many > > years. > > > > "I hope everyone has a good rest of the weekend." - Yes, I'm making > sure of it. > > > > Everyone need to stay tuned because there is a new technical > solution > > for tomorrow (how to dramatically lower DDoS attacks, a beautiful > one). > > > > Respectfully, > > Elad > > *From:* members-discuss on behalf > of > > Ben Fitzgerald-O'Connor > > *Sent:* Sunday, April 26, 2020 7:52 PM > > *To:* Silvan Gebhardt ; > > members-discuss at ripe.net > > *Subject:* Re: [members-discuss] [SPAM] Technical Solution to > resolve > > the global "Email Spam" problem > > Hi All, > > > > > > I generally lurk here but a small comment on this.. > > > > > > Reading the thread, my humble opinion: > > > > > > @Elad ? noting the comments, I think I do agree that email problems > / > > solutions might be better submitted as an RFC > > (https://www.ietf.org/standards/rfcs/) .. Ripe is a LIR mainly > tasked > > with administering IP number resources. ? At the same time, I do > love > > your obvious passion for addressing problems and looking freshly at > > possible solutions. Regarding the upcoming election ? I have just > had a > > look at the page with Candidate Biographies to judge a little how I > > might vote ? at > > > https://www.ripe.net/participate/meetings/gm/meetings/may-2020/candidate-biographies .. and I can?t see you there, so would suggest please to submit / add a biography if this is not already in the works (and I hope all candidates do too). > > > > > > NB ? be careful that if you do come up with a solution to fix spam > once > > and for all then beware that you also put a USD $10 Billion value on > > your own head (this is the rough value annually of the anti-spam > > industry!) (Comment partly in jest, partly from experience and > > observation). > > > > > > I hope everyone has a good rest of the weekend. > > > > > > Regards > > > > Ben > > > > > > *From:* members-discuss *On > Behalf > > Of *Silvan Gebhardt > > *Sent:* 26 April 2020 17:33 > > *To:* members-discuss at ripe.net > > *Subject:* Re: [members-discuss] [SPAM] Technical Solution to > resolve > > the global "Email Spam" problem > > > > > > Hi Michael, > > > > > > this is not about any technical solution. This is Elad trying to > > position himself for the upcoming election. > > > > This is an election campaign. Nothing more. > > > > > > > https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates > > > > > > Elon, just save your next typing. You will immead scream that I am > > running an "illegal cyber defamation campaign" against you. Sure. > > whatever. > > > > > > > > Silvan > > > > On 4/26/20 4:22 PM, info at cowmedia.de wrote: > > > > > Sorry Elad, > > > > > > > i know ist Sunday and some members of this mailling list have more > time as on a busy working day but are you really again (see the other > topic) posting an idea in this list were we cannot do anything about > this? > > > > > > > You try to find or present solutions to problems that doesnt > exist. While you think a lot on your ideas technically, please note > that this is only 1/3 of the things you need to take care of. > > > > > In this specific case you want to outsource the servers job of > filtering SPAM out competely to the client. This is not how this was > designed. You are thinking that email clients always have a UI or at > least some bigger code behind it that is able to do a lot of stuff. > There exist email clients in the world that have only <100 lines of > code and are only text based (as email is from the ground up). > > > > > > > We are completely the wrong audience group for your emails. > > > > > > > Michael > > > > > > > > _______________________________________________ > > members-discuss mailing list > > members-discuss at ripe.net > > https://lists.ripe.net/mailman/listinfo/members-discuss > > Unsubscribe: > > > https://lists.ripe.net/mailman/options/members-discuss/nevin%40arcustech.com > > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/elad%40netstyle.io -- -- Nevin Lyne -- Founder and Director of Technology -- Arcustech, LLC - https://www.arcustech.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksi at magnacapax.fi Sun Apr 26 20:04:56 2020 From: aleksi at magnacapax.fi (Aleksi) Date: Sun, 26 Apr 2020 21:04:56 +0300 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> Message-ID: a centralized solution ... Yikes! Next step permits for email, only to be approved by government officials? For spam review purposes all emails must be stored centrally? Certainly no abuse will ever happen. On 4/26/20 7:50 PM, Matthias Brumm wrote: > > Hi! > > > To understand correctly. You want to enforce, that every subscribe > operation / e-mail client operation (get new email from server) in the > world will make a bidirectional communication with a central server? > Do you have an ellaborated guess, how much computing power that would > need? > > > Matthias > > > Am 26.04.20 um 18:05 schrieb Elad Cohen: >> Hello Everyone, >> >> I want to share with you my technical solution to resolve the global >> world "Email Spam" problem and in addition it will also resolve the >> spreading of illegal links (phishing/malware/etc , once the sites are >> known) through electronic mail and will stop email spoofing (that >> part using current technologies). >> >> Email spam problem was not being able to be defeated since the >> beginning of electronic mail, as long as email spam will be >> profitable to email spammers - it will exist, email spam caused the >> illegal anonymous organization "The Spamhaus Project" to exist, "The >> Spamhaus Project" is hurting and damaging many businesses worldwide >> in their way to fight email spam, "The Spamhaus Project" is an >> illegal anonymous organization according to the following >> presentation that they wrote on themselves, they are violating laws >> in their way to fight email spam and still they don't win in the >> battle against email spam. "The Spamhaus Project" is keeping their >> anonymity because they are afriad of justified lawsuits due to their >> criminal actions in their way to fight email spam. The following >> technical solution will resolve the world email spam problem without >> to hurt and to damage many businesses worldwide that have nothing to >> do with email spam like "The Spamhaus Project" does, the following >> implementation can remove the need for an illegal anonymous >> organization such as "The Spamhaus Project". >> >> >> The presentation that the illegal anonymous organization "The >> Spamhaus Project" wrote on themselves: >> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >> >> >> >> The Implementation: >> >> There will be a site (lets call it NoSpam.org) - the site will be >> owned by the 5 RIRs, the site will use bgp anycast and will be >> deployed in each of the 5 RIRs (the site will also be able to be >> deployed by the ccTLD registries in each country), the site in all >> the locations will be synced automatically. >> >> Each domain owner will be able to register at the site (an email >> message will be sent to the domain owner email address in the domain >> name WHOIS details in order to verify that the domain owner is the >> one registering). >> >> After being logged in, a domain owner will be able to add his email >> addresses (of the specific domain name) that will be used to send >> newsletters / mailing lists / one-to-many email messages, lets call >> these kind of email addresses as 'mailing list' email addresses. The >> domain owner will not be able to see the list of 'mailing list' email >> addresses that he added - because when he added each 'mailing list' >> email address it will be saved with hash in the NoSpam.org backend >> infrastructure (due to privacy and security reasons) - hence only if >> the domain owner will manually type the 'mailing list' email address >> he will be able to enter it in order to manage it (to see the total >> number of subscribers email addresses, to see the subscribers email >> addresses but only with their hashes due to security and privacy >> reasons, to remove a subscriber from the list, to add a sub-user with >> permissions to manage that specific 'mailing list' email address). >> >> In his site, the domain owner will be able to integrate an iframe >> from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a >> subscriber registration form to his specific 'mailing list' email >> address, the subscriber will receive an email message with a link to >> confirm his subscription. >> >> The domain owner will need to create a callback file in his website, >> for example in the path: "/nospam-notification-callback" >> (http://example.com/nospam-notification-callback) - that url will >> receive encrypted post notifications (encryption key will be provided >> by the domain owner in his NoSpam.org logged in account) from >> NoSpam.org regarding any new end-user that will subscribe or that >> will unsubscribe from a 'mailing address' email address which is >> related to the domain of the domain owner (unsubscribe functionality >> by the user later below). >> >> The subscriber email address and that 'mailing list' email address >> (that was subscribed to) will be sent by NoSpam.org to >> "/nospam-notification-callback" not in the hashed format but in >> cleartext (so the domain owner will be able to save it in his system >> for future email messages from the specific 'mailing list' email >> address to the specific subscriber email address). >> >> The domain owner will also have an API to NoSpam.org backend >> infrastructure in order to remove a specific subscriber email address >> from a specific 'mailing list' email address (the domains owner will >> send the values through the API - hashed). >> >> The domain owner will also provide a web interface in his site for >> the end-user to remove himself from the specific 'mailing list' email >> address. >> >> >> >> The above is the backend implementation (no upgrade is needed to any >> email server in the internet), the following is the upgrade that will >> needed for any email client (that upgrade is not mandatory, without >> the following upgrade the email client will work exactly as it is now >> without the added no-spam features, electronic mail will not break if >> some email users will upgrade their email clients and some will not): >> >> - There will not be 'mark as spam' button, that kind of functionality >> will stop to exist because spam is not a boolean value, 'spam' to one >> person is valuable to another 'person', specially when the internet >> is global and different people from different countries will consider >> spam content differently. One user can consider an email message as >> spam and another user can consider the same message as not spam, >> 'Spam' is subjective and any kind of 'mark as spam' functionality is >> useless in the battle against email spam. >> >> - There will be blacklists and whitelists (just like there are now, >> but they will be more prominent): blacklist email addresses , >> blacklist domains , whitelist email addresses , whitelist domains. >> >> - The end-user should be able to easily enter each email message to >> whitelist or to blacklist (meaning the 'from' email address of the >> email message), and will be able to search in the 'Spam' folder >> easily for an email address (these features can exist today, but they >> should be given more visibility, so end-users will use them more). >> >> - The end-user will be able to import/export his whitelists and >> blacklists using an xml format to any other upgraded email client, >> the blacklists and whitelists will be local (end-user will be able to >> pass the local whitelists and blacklists to another email client of >> his with the click of a button in the upgraded email client - the >> upgraded email client will just send them to itself - without to >> download them from the email server so the end-user will be able to >> download it with another upgraded email client - or the end-user will >> be able to send the whitelists and blacklists to another email >> address of him, the usage will not be like sending regular email >> message with attachments - the upgraded email clients will take care >> to sending and receiving of the blacklists and whitelits - in the >> background, these are custom formatted email messages that the two >> upgraded email clients will know how to act upon them). >> >> - The email client will be able to display with GUI with buttons any >> 'mailing-list registration confirmation email' in a specific section >> related to registration to new 'mailing list' email addresses for the >> end-user to choose with buttons if he accept or refuse to register to >> a specific 'mailing list' email address. >> >> - For any email message that was received: in case a received 'from' >> email address was found in the whitelist email addresses or in the >> whitelist domains - then it will be moved to the 'Inbox' folder, in >> case the 'from' email address of the email message was found in the >> blacklist email addresses or in the blacklist domains - then the >> email message will be moved to the 'Trash' folder. >> >> - In case the 'from' email address or domain was not found in the >> whitelists and in the blacklists, then the upgraded email client will >> send the 'from' email address and the 'from' domain and the current >> user email address and the external links that exist in the email >> message (but all of these data will be sent in a hashed way, and not >> in cleartext) with a query to NoSpam.org backend infrastructure, >> NoSpam.org will perform the following algorithem after it: >> >> - If the hashed 'from' domain (or any other 'hashed' domain from the >> external links) exist in a list of criminals hashed domains (of >> phishing/malware/viruses/etc) then NoSpam.org will respond to the >> email client to delete the email message, otherwise the hashed 'from' >> email address will be checked against a list of hashed 'mailing list' >> email addresses - if found then the sender is a 'mailing list' email >> address and there will be a check by NoSpam.org backend >> infrastructure if the hashed 'receiver' email address is a subscriber >> of that specific 'mailing list' email address , if the hashed >> 'receiver' was found then NoSpam.org will send a response to the >> email client that the email message can be displayed in the 'Inbox' >> folder and in the response NoSpam.org will also include an >> unsubscribe key - the email client will be able to display an >> unsubscribe button to the email client and if clicked the email >> client will send an https request to NoSpam.org with the specific >> unsubscribe key, NoSpam.org backend infrastructure will remove the >> end-user email address from the 'mailing list' email address and will >> notify the domain owner at the domain owner callback url >> "/nospam-notification-callback" that the specific user unsubscribed. >> In case the hashed 'receiver' wasn't found then NoSpam.org will >> respond to the email client to delete the email message and >> NoSpam.org will also notify the callback url of the related domain >> owner that he shouldn't send email messages from the specific >> 'mailing ?list' email address to the specific subscriber email address. >> >> - In case when NoSpam.org backend infrastructure searched the hashed >> 'from' email address and it wasn't found in the list of all hashed >> 'mailing list' email addresses, it mean that the email address was >> sent from a 'personal' email address and NoSpam.org backend >> infrastructure will notify the email client that the email message is >> from a 'personal' email address - the email client in that stage will >> need to decide if to move the email message to the 'Inbox' folder or >> to the 'Spam' folder based on the following - the email client will >> check if the email message include links/images/plain-url's - and if >> yes then the email message will be moved to the 'Spam' folder, >> otherwise it will be moved to the 'Inbox' folder. >> >> >> >> >> Whitelist Handshake: >> >> - In order to facilitate the adding of new email address to the local >> whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist >> Handshake' is a GUI representation in two email clients regarding >> background email messages between them (that the two end-users don't >> see), "end-user A" with a click of a button will be able to send 'add >> me to whitelist' request to "end-user B" which will be able to accept >> or deny and if accepted then "end-user B" will be able to >> automatically send the same "add me to whitelist" request to >> "end-user A" , all of this communication will be done behind the >> scenes, these special email messages will not be visible to the >> end-users, end-users will see popups with GUI that email address X is >> asking to be added to whitelist. In order for spammers not to abuse >> this option - the email client will keep only one 'whitelist request' >> from each requester email address (there will be a 'whitelist >> requests' section in the upgraded email client). A repeated >> 'whitelist request' that came from a specific email address can never >> be raised in the list (unless the end-user will specifically search >> for it) even when the sender will send more and more 'add me to >> whitelist' requests - no priority will given to them, and once an >> end-user refused an 'add me to whitelist' request - no new 'add me to >> whitelist' request will be shown from the specific sender email >> address in the specific email client. >> >> - There can be a case that an upgraded email client will send 'add me >> to whitelist' request to a not-upgraded email client and then the >> receiver will see the request as it is - as an email message in the >> inbox folder - due to it the content of that message will be in the >> language of the domain TLD of the receiver email address and the >> content in the email message will explain what is NoSpam.org and how >> to upgrade the email client and supported upgraded email clients, etc >> >> - In the 'whitelist requests section' in the upgraded email client - >> the whitelist requests will appear in a list - there should be >> preference so some requests will appear upper and other lower (so >> requests from spammers will appear lower) - whitelist requests from >> email addresses of domains which are older (according to their WHOIS >> details) will appear upper than whitelist requests from email >> addresses of domains which are newer. Whitelist requests from a list >> of a more-trusted-domains (domains of known webmails service, >> universities, governments, etc) will have preference over other >> domains, specific TLDs that not anyone can purchase will also have >> preference over other TLDs that anyone can purchase (upgraded email >> clients will retrieve the list of trusted TLD's and Domains each day >> from NoSpam.org backend infrastructure). >> >> >> Notification of spam emails: >> >> - An additional feature in the upgraded email client is that whenever >> an email message will reach the 'Spam' folder - the email client will >> send in the background a known-format email message to the sender and >> will notify him about it, if the sender is using an upgraded email >> client then it will be able to automatically send a 'add me to >> whitelist' request to the receiver in the background (once an email >> address is whitelisted - all the email messages from it will move >> from 'Spam' to 'Inbox'). >> >> >> >> Email Spoofing: >> >> - In an upgraded email client, email messages from 'personal' email >> addresses cannot arrive from email relay server, in case it happen >> the message will be deleted and the email client will send an >> automatic email message in the background to the sender with the text >> (in the language of the sender domain TLD) that email messages from >> 'email relay servers' cannot be received from him. >> >> - In an upgraded email client, email messages from 'mailing list' >> email addresses can arrive from email relay servers - but they must >> be encrypted with DKIM. >> >> - In an upgraded email client, the email client should check the SPF >> txt dns record of the sender domain, and will drop the email message >> if it is a spoofed email message. >> >> - DNS servers developers will need to make the SPF txt dns record to >> be a mandatory field for every domain, in order for email spoofing to >> be annihilated. >> >> >> >> Security Aspects: >> >> - All stored data in NoSpam.org Backend infrastructure is hashed. >> >> - The criminals domains list in NoSpam.org Backend Infrastructure >> will be managed only by regulated supervised Law Enforcement Agency >> (for example: Interpol) and not by an internet organization such as >> the RIRs or ccTLD registries. >> >> - Domains owners will have 'forgot password' functionality to their >> NoSpam.org account, the password reset link will be sent to the email >> address of the owner of the domain according to the domain WHOIS details. >> >> - Communication between email clients to NoSpam.org backend >> infrastructure will be over https, there will only be an handshake >> process in the beginning over electronic mail between email client >> and NoSpam.org backend infrastructure - the email client will send an >> email message with a chosen key to an email address of @nospam.org >> (that key will be used in further communication between the email >> client and the NoSpam.org backend infrastructure over https, it will >> be used for NoSpam.org backend infrastructure to identify the >> specific email address over https, so anyone will not be able to >> query NoSpam.org backend infrastructure to know which hashed email >> address belongs to which hashed 'mailing list' email address, besides >> the email client user with the right key to query NoSpam.org Backend >> infrastructure only on himself). >> >> - Any email client will download once per day 'spam-rules' file from >> NoSpam.org backend infrastructure, 'spam-rules' file will be an xml >> formatted file that include rules of when to move an email message >> that was received from 'personal' email address which is not >> whitelisted to the 'Spam' folder (for example, when email have at >> least 1/2/3 links, when email format is rich text or html and not >> plaintext, etc), in case future adjustments will be needed to win the >> battle against email spam - email clients will not need to be >> upgraded, the new 'spam-rules' will be updated in this daily file. >> >> >> To make it short: >> >> - Any email message from a subscribed mailing list / newsletter / etc >> - will reach to the inbox (that kind of email messages can contain >> any kind of content without any restrictions, because the user >> subscribed to it and the user can unsubscribe from it at anytime). >> >> - Any email message from an email address or domain in whitelist - >> will reach the inbox. >> >> - Whitelist Handshake process is easy to use and being implemented >> with clicks of a button, nothing to type. >> >> - In case an email message will the 'Spam' folder - an automatic >> email message will be sent from the receiver to sender and sender can >> automatically ask to be added to the receiver's whitelist. >> >> - Any email message without links/images/plain-url's (plain email >> messages, like electronic email was) - will reach the inbox. >> >> - Any other email will reach the 'Spam' folder - if needed the user >> will be able to easily whitelist the email message in the 'Spam' folder. >> >> >> >> Spammers need links in their email messages for monetization, above >> solution blocks it and also block criminal domains links in email >> message and implement email spoofing blocking at client-side. We will >> all stop to receive more than 100 spam email messages per day with >> the above solution. >> >> >> Respectfully, >> Elad >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net > -- > Unser Familien-Blog:https://brumm.family > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi -------------- next part -------------- An HTML attachment was scrubbed... URL: From franco.tauceri at domainregister.it Sun Apr 26 20:13:47 2020 From: franco.tauceri at domainregister.it (Franco Tauceri) Date: Sun, 26 Apr 2020 20:13:47 +0200 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> , <8b747a3e-3b93-9c23-4003-1e9fed67a3ad@brumm.net> Message-ID: <32fbde974c39509a6176477ec213e337@domainregister.it> In the meanwhile we're waiting for next Elad's idea to save the planet, I suggest a little move that will contribute to a little reduction of spam: is it kindly possible to remove him from this list (that, it's clear, he as no understood the goal of this list...) ? Regards -- Franco Tauceri DomainRegister m: 39.3483064202 w: https://DomainRegister.international e: franco.tauceri at domainregister.it On 26/04/2020 07:31 PM, Elad Cohen wrote: >> >> Hello, >> >> Ripe have 30 millions euros of expenses each year that are hidden and now shown to where exactly they are paid, instead of that corruption - a small part of the money can be used also for the deployment of IPv4+ and also for NoSpam.org and also for the next solution that I will present regarding how to dramatically lower ddos attacks, a simple and elegant solution that will help each and every ASN in the world. >> >> Respectfully, >> Elad >> >> ------------------------- >> >> From: Matthias Brumm >> Sent: Sunday, April 26, 2020 8:27 PM >> To: Elad Cohen ; Jetten Raymond ; members-discuss at ripe.net >> Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem >> >> Hi! >> >> Maybe, but no one here is in the position to make such a project work instantly. >> >> To get it rolling, this may be easier than IPv4+. Present a working proof-of-concept with nospan.org and a Thunderbird-Plug-In. Then try to get the E-Mail-Clients on board. As long as the nospam.org servers are scalable, you can grow very fast. >> >> Matthias >> >> Am 26.04.20 um 19:20 schrieb Elad Cohen: > Jetten, > > This is not up to you to decide. > > This is a membership discuss mailing list, I'm a member just like you are, please don't shut conversations and tell what we can or cannot talk about, Spam is a problem that is related to all Ripe LIR members including you. > > Respectfully, > Elad > ------------------------- > > From: members-discuss on behalf of Jetten Raymond > Sent: Sunday, April 26, 2020 8:04 PM > To: members-discuss at ripe.net ; Matthias Brumm > Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem > > This list is NOT for technical related posts, it is for MEMBERSHIP related issues. Please move the discussion elsewhere. > > L?hetetty Outlook Mobilesta [1] > ------------------------- > > From: members-discuss on behalf of Matthias Brumm > Sent: Sunday, April 26, 2020 7:50:23 PM > To: members-discuss at ripe.net > Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem > > Hi! > > To understand correctly. You want to enforce, that every subscribe operation / e-mail client operation (get new email from server) in the world will make a bidirectional communication with a central server? Do you have an ellaborated guess, how much computing power that would need? > > Matthias > > Am 26.04.20 um 18:05 schrieb Elad Cohen: > Hello Everyone, > > I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). > > Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". > > The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: > https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation > > The Implementation: > > There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. > > Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). > > After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). > > In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. > > The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). > > The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). > > The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). > > The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. > > The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): > > - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. > > - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. > > - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). > > - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). > > - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. > > - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. > > - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: > > - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. > > - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. > > Whitelist Handshake: > > - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. > > - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc > > - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). > > Notification of spam emails: > > - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). > > Email Spoofing: > > - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. > > - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. > > - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. > > - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. > > Security Aspects: > > - All stored data in NoSpam.org Backend infrastructure is hashed. > > - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. > > - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. > > - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). > > - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. > > To make it short: > > - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). > > - Any email message from an email address or domain in whitelist - will reach the inbox. > > - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. > > - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. > > - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. > > - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. > > Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. > > Respectfully, > Elad > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net > > -- > Unser Familien-Blog: https://brumm.family -- Unser Familien-Blog: https://brumm.family _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/franco.tauceri%40domainregister.it Links: ------ [1] https://aka.ms/blhgte -------------- next part -------------- An HTML attachment was scrubbed... URL: From href at fastmail.net Sun Apr 26 20:14:50 2020 From: href at fastmail.net (Jordan Bracco) Date: Sun, 26 Apr 2020 20:14:50 +0200 Subject: [members-discuss] =?utf-8?q?Technical_Solution_to_resolve_the_gl?= =?utf-8?q?obal_=22Email_Spam=22_problem?= In-Reply-To: References: <2fad3198-4fcc-4783-98ed-cbb2cc0a30de@www.fastmail.com> Message-ID: Elad, I do not see what you mean by "telling a lie again and again". I have a vague memory of something fishy going on with a Cape Town ip block, but there was many occurences like this. I cited Cape Town as an example. I do not have proof, so maybe the Cape Town is a false memory, but IP hijacking (which was the subject of my email, not Cape Town) surely do happen. For the rest of your reply-- I just simply do not understand it. - I fail to see a correlation between hijacking IP space and Spamhaus. Could you please enlighten me ? - I also fail to understand what you mean by "mob friends just like you". I have no relationship whatsoever with SpamHaus, I do not use their DNSBLs (as I delegate most of my emails to Fastmail). I was just asking for your thoughts and technical solutions to IP space hijacking. Your reply turned into a rant about Spamhaus (?) and accusing me of being "mob friend" of it (?) ? On Sun, Apr 26, 2020, at 19:46, Elad Cohen wrote: > Jordan, > > What you are writing is false, telling a lie again and again will not make it truth. > > "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) > > And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: > > https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation > > "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. > > Respectfully, > Elad > > > > *From:* members-discuss on behalf of Jordan Bracco > *Sent:* Sunday, April 26, 2020 8:23 PM > *To:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem > > Dear Elad, > > Unrelated to the spam proposal-- but have you found a technical solution to avoid malicious third parties to hijack assigned IP space (for example, if I remember that there was some IP space from Cape Town city that got hijacked). What are you thoughts on this, and your technical solution to it ? > > > On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: >> Hello Everyone, >> >> I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). >> >> Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". >> >> >> The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: >> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >> >> >> >> The Implementation: >> >> There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. >> >> Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). >> >> After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). >> >> In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. >> >> The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). >> >> The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). >> >> The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). >> >> The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. >> >> >> >> The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): >> >> - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. >> >> - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. >> >> - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). >> >> - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). >> >> - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. >> >> - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. >> >> - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: >> >> - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. >> >> - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. >> >> >> >> >> Whitelist Handshake: >> >> - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. >> >> - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc >> >> - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). >> >> >> Notification of spam emails: >> >> - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). >> >> >> >> Email Spoofing: >> >> - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. >> >> - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. >> >> - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. >> >> - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. >> >> >> >> Security Aspects: >> >> - All stored data in NoSpam.org Backend infrastructure is hashed. >> >> - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. >> >> - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. >> >> - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). >> >> - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. >> >> >> To make it short: >> >> - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). >> >> - Any email message from an email address or domain in whitelist - will reach the inbox. >> >> - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. >> >> - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. >> >> - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. >> >> - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. >> >> >> >> Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. >> >> >> Respectfully, >> Elad >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 20:23:43 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 18:23:43 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <2fad3198-4fcc-4783-98ed-cbb2cc0a30de@www.fastmail.com> , Message-ID: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. ---- Can you show a single proof to what you are writing? You are taking part in an illegal cyber influence operation against me. Respectfully, Elad ________________________________ From: Jordan Bracco Sent: Sunday, April 26, 2020 9:14 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad, I do not see what you mean by "telling a lie again and again". I have a vague memory of something fishy going on with a Cape Town ip block, but there was many occurences like this. I cited Cape Town as an example. I do not have proof, so maybe the Cape Town is a false memory, but IP hijacking (which was the subject of my email, not Cape Town) surely do happen. For the rest of your reply-- I just simply do not understand it. - I fail to see a correlation between hijacking IP space and Spamhaus. Could you please enlighten me ? - I also fail to understand what you mean by "mob friends just like you". I have no relationship whatsoever with SpamHaus, I do not use their DNSBLs (as I delegate most of my emails to Fastmail). I was just asking for your thoughts and technical solutions to IP space hijacking. Your reply turned into a rant about Spamhaus (?) and accusing me of being "mob friend" of it (?) ? On Sun, Apr 26, 2020, at 19:46, Elad Cohen wrote: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. Respectfully, Elad ________________________________ From: members-discuss on behalf of Jordan Bracco Sent: Sunday, April 26, 2020 8:23 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Dear Elad, Unrelated to the spam proposal-- but have you found a technical solution to avoid malicious third parties to hijack assigned IP space (for example, if I remember that there was some IP space from Cape Town city that got hijacked). What are you thoughts on this, and your technical solution to it ? On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 20:24:49 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 18:24:49 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <32fbde974c39509a6176477ec213e337@domainregister.it> References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> , <8b747a3e-3b93-9c23-4003-1e9fed67a3ad@brumm.net> , <32fbde974c39509a6176477ec213e337@domainregister.it> Message-ID: Not the plant, just to reduce dramatically ddos attacks. Respectfully, Elad ________________________________ From: Franco Tauceri Sent: Sunday, April 26, 2020 9:13 PM To: Elad Cohen Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In the meanwhile we're waiting for next Elad's idea to save the planet, I suggest a little move that will contribute to a little reduction of spam: is it kindly possible to remove him from this list (that, it's clear, he as no understood the goal of this list...) ? Regards -- [https://domainregister.international/templates/dr/assets/images/dr-logo.svg] Franco Tauceri DomainRegister m: 39.3483064202 w: https://DomainRegister.international e: franco.tauceri at domainregister.it On 26/04/2020 07:31 PM, Elad Cohen wrote: Hello, Ripe have 30 millions euros of expenses each year that are hidden and now shown to where exactly they are paid, instead of that corruption - a small part of the money can be used also for the deployment of IPv4+ and also for NoSpam.org and also for the next solution that I will present regarding how to dramatically lower ddos attacks, a simple and elegant solution that will help each and every ASN in the world. Respectfully, Elad ________________________________ From: Matthias Brumm Sent: Sunday, April 26, 2020 8:27 PM To: Elad Cohen ; Jetten Raymond ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hi! Maybe, but no one here is in the position to make such a project work instantly. To get it rolling, this may be easier than IPv4+. Present a working proof-of-concept with nospan.org and a Thunderbird-Plug-In. Then try to get the E-Mail-Clients on board. As long as the nospam.org servers are scalable, you can grow very fast. Matthias Am 26.04.20 um 19:20 schrieb Elad Cohen: Jetten, This is not up to you to decide. This is a membership discuss mailing list, I'm a member just like you are, please don't shut conversations and tell what we can or cannot talk about, Spam is a problem that is related to all Ripe LIR members including you. Respectfully, Elad ________________________________ From: members-discuss on behalf of Jetten Raymond Sent: Sunday, April 26, 2020 8:04 PM To: members-discuss at ripe.net ; Matthias Brumm Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem This list is NOT for technical related posts, it is for MEMBERSHIP related issues. Please move the discussion elsewhere. L?hetetty Outlook Mobilesta ________________________________ From: members-discuss on behalf of Matthias Brumm Sent: Sunday, April 26, 2020 7:50:23 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hi! To understand correctly. You want to enforce, that every subscribe operation / e-mail client operation (get new email from server) in the world will make a bidirectional communication with a central server? Do you have an ellaborated guess, how much computing power that would need? Matthias Am 26.04.20 um 18:05 schrieb Elad Cohen: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family -- Unser Familien-Blog: https://brumm.family _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/franco.tauceri%40domainregister.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold.dech at adct.be Sun Apr 26 20:27:04 2020 From: arnold.dech at adct.be (Arnold Dechamps) Date: Sun, 26 Apr 2020 20:27:04 +0200 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <32fbde974c39509a6176477ec213e337@domainregister.it> References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> <8b747a3e-3b93-9c23-4003-1e9fed67a3ad@brumm.net> <32fbde974c39509a6176477ec213e337@domainregister.it> Message-ID: Spam... Plus the fact that this guy appears to have some link in BGP Hijacking cases... (sources : https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-address-heist-how-millions-are-made-on-the-grey-market.html) On 4/26/20 8:13 PM, Franco Tauceri wrote: > In the meanwhile we're waiting for next Elad's idea to save the > planet, I suggest a little move that will contribute to a little > reduction of spam:?is it kindly possible to remove him from this list > (that, it's clear, he as no understood the goal of this list...) ? > > Regards > > -- > > Franco Tauceri > *DomainRegister* > m: 39.3483064202 > w: > https://DomainRegister.international??e:?franco.tauceri at domainregister.it > > > > On 26/04/2020 07:31 PM, Elad Cohen wrote: > >>> ? >>> Hello, >>> ? >>> Ripe have 30 millions euros of expenses each year that are hidden >>> and now shown to where exactly they are paid, instead of that >>> corruption - a small part of the money can be used also for the >>> deployment of IPv4+ and also for NoSpam.org and also for the next >>> solution that I will present regarding how to dramatically lower >>> ddos attacks, a simple and elegant solution that will help each and >>> every ASN in the world. >>> ? >>> Respectfully, >>> Elad >>> ? >>> ------------------------------------------------------------------------ >>> *From:* Matthias Brumm >>> *Sent:* Sunday, April 26, 2020 8:27 PM >>> *To:* Elad Cohen ; Jetten Raymond >>> ; members-discuss at ripe.net >>> >>> *Subject:* Re: [members-discuss] Technical Solution to resolve the >>> global "Email Spam" problem >>> ? >>> >>> Hi! >>> >>> >>> Maybe, but no one here is in the position to make such a project >>> work instantly. >>> >>> >>> To get it rolling, this may be easier than IPv4+. Present a working >>> proof-of-concept with nospan.org and a Thunderbird-Plug-In. Then try >>> to get the E-Mail-Clients on board. As long as the nospam.org >>> servers are scalable, you can grow very fast. >>> >>> >>> Matthias >>> >>> >>> Am 26.04.20 um 19:20 schrieb Elad Cohen: >>>> Jetten, >>>> ? >>>> This is not up to you to decide. >>>> ? >>>> This is a membership discuss mailing list, I'm a member just like >>>> you are, please don't shut conversations and tell what we can or >>>> cannot talk about, Spam is a problem that is related to all Ripe >>>> LIR members including you. >>>> ? >>>> Respectfully, >>>> Elad >>>> ------------------------------------------------------------------------ >>>> *From:* members-discuss >>>> on behalf of Jetten >>>> Raymond >>>> *Sent:* Sunday, April 26, 2020 8:04 PM >>>> *To:* members-discuss at ripe.net >>>> ; >>>> Matthias Brumm >>>> *Subject:* Re: [members-discuss] Technical Solution to resolve the >>>> global "Email Spam" problem >>>> ? >>>> This list is NOT for technical related posts, it is for MEMBERSHIP >>>> related issues. Please move the discussion elsewhere. >>>> >>>> L?hetetty Outlook Mobilesta >>>> ------------------------------------------------------------------------ >>>> *From:* members-discuss >>>> on behalf of Matthias >>>> Brumm >>>> *Sent:* Sunday, April 26, 2020 7:50:23 PM >>>> *To:* members-discuss at ripe.net >>>> >>>> *Subject:* Re: [members-discuss] Technical Solution to resolve the >>>> global "Email Spam" problem >>>> ? >>>> >>>> Hi! >>>> >>>> >>>> To understand correctly. You want to enforce, that every subscribe >>>> operation / e-mail client operation (get new email from server) in >>>> the world will make a bidirectional communication with a central >>>> server? Do you have an ellaborated guess, how much computing power >>>> that would need? >>>> >>>> >>>> Matthias >>>> >>>> >>>> Am 26.04.20 um 18:05 schrieb Elad Cohen: >>>> Hello Everyone, >>>> ? >>>> I want to share with you my technical solution to resolve the >>>> global world "Email Spam" problem and in addition it will also >>>> resolve the spreading of illegal links (phishing/malware/etc , once >>>> the sites are known) through electronic mail and will stop email >>>> spoofing (that part using current technologies). >>>> ? >>>> Email spam problem was not being able to be defeated since the >>>> beginning of electronic mail, as long as email spam will be >>>> profitable to email spammers - it will exist, email spam caused the >>>> illegal anonymous organization "The Spamhaus Project" to exist, >>>> "The Spamhaus Project" is hurting and damaging many businesses >>>> worldwide in their way to fight email spam, "The Spamhaus Project" >>>> is an illegal anonymous organization according to the following >>>> presentation that they wrote on themselves, they are violating laws >>>> in their way to fight email spam and still they don't win in the >>>> battle against email spam. "The Spamhaus Project" is keeping their >>>> anonymity because they are afriad of justified lawsuits due to >>>> their criminal actions in their way to fight email spam. The >>>> following technical solution will resolve the world email spam >>>> problem without to hurt and to damage many businesses worldwide >>>> that have nothing to do with email spam like "The Spamhaus Project" >>>> does, the following implementation can remove the need for an >>>> illegal anonymous organization such as "The Spamhaus Project". >>>> ? >>>> ? >>>> The presentation that the illegal anonymous organization "The >>>> Spamhaus Project" wrote on themselves: >>>> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >>>> ? >>>> ? >>>> ? >>>> The Implementation: >>>> ? >>>> There will be a site (lets call it NoSpam.org) - the site will be >>>> owned by the 5 RIRs, the site will use bgp anycast and will be >>>> deployed in each of the 5 RIRs (the site will also be able to be >>>> deployed by the ccTLD registries in each country), the site in all >>>> the locations will be synced automatically. >>>> ? >>>> Each domain owner will be able to register at the site (an email >>>> message will be sent to the domain owner email address in the >>>> domain name WHOIS details in order to verify that the domain owner >>>> is the one registering). >>>> ? >>>> After being logged in, a domain owner will be able to add his email >>>> addresses (of the specific domain name) that will be used to send >>>> newsletters / mailing lists / one-to-many email messages, lets call >>>> these kind of email addresses as 'mailing list' email addresses. >>>> The domain owner will not be able to see the list of 'mailing list' >>>> email addresses that he added - because when he added each 'mailing >>>> list' email address it will be saved with hash in the NoSpam.org >>>> backend infrastructure (due to privacy and security reasons) - >>>> hence only if the domain owner will manually type the 'mailing >>>> list' email address he will be able to enter it in order to manage >>>> it (to see the total number of subscribers email addresses, to see >>>> the subscribers email addresses but only with their hashes due to >>>> security and privacy reasons, to remove a subscriber from the list, >>>> to add a sub-user with permissions to manage that specific 'mailing >>>> list' email address). >>>> ? >>>> In his site, the domain owner will be able to integrate an iframe >>>> from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a >>>> subscriber registration form to his specific 'mailing list' email >>>> address, the subscriber will receive an email message with a link >>>> to confirm his subscription. >>>> ? >>>> The domain owner will need to create a callback file in his >>>> website, for example in the path: "/nospam-notification-callback" >>>> (http://example.com/nospam-notification-callback) - that url will >>>> receive encrypted post notifications (encryption key will be >>>> provided by the domain owner in his NoSpam.org logged in account) >>>> from NoSpam.org regarding any new end-user that will subscribe or >>>> that will unsubscribe from a 'mailing address' email address which >>>> is related to the domain of the domain owner (unsubscribe >>>> functionality by the user later below). >>>> ? >>>> The subscriber email address and that 'mailing list' email address >>>> (that was subscribed to) will be sent by NoSpam.org to >>>> "/nospam-notification-callback" not in the hashed format but in >>>> cleartext (so the domain owner will be able to save it in his >>>> system for future email messages from the specific 'mailing list' >>>> email address to the specific subscriber email address). >>>> ? >>>> The domain owner will also have an API to NoSpam.org backend >>>> infrastructure in order to remove a specific subscriber email >>>> address from a specific 'mailing list' email address (the domains >>>> owner will send the values through the API - hashed). >>>> ? >>>> The domain owner will also provide a web interface in his site for >>>> the end-user to remove himself from the specific 'mailing list' >>>> email address. >>>> ? >>>> ? >>>> ? >>>> The above is the backend implementation (no upgrade is needed to >>>> any email server in the internet), the following is the upgrade >>>> that will needed for any email client (that upgrade is not >>>> mandatory, without the following upgrade the email client will work >>>> exactly as it is now without the added no-spam features, electronic >>>> mail will not break if some email users will upgrade their email >>>> clients and some will not): >>>> ? >>>> - There will not be 'mark as spam' button, that kind of >>>> functionality will stop to exist because spam is not a boolean >>>> value, 'spam' to one person is valuable to another 'person', >>>> specially when the internet is global and different people from >>>> different countries will consider spam content differently. One >>>> user can consider an email message as spam and another user can >>>> consider the same message as not spam, 'Spam' is subjective and any >>>> kind of 'mark as spam' functionality is useless in the battle >>>> against email spam. >>>> ? >>>> - There will be blacklists and whitelists (just like there are now, >>>> but they will be more prominent): blacklist email addresses , >>>> blacklist domains , whitelist email addresses , whitelist domains. >>>> ? >>>> - The end-user should be able to easily enter each email message to >>>> whitelist or to blacklist (meaning the 'from' email address of the >>>> email message), and will be able to search in the 'Spam' folder >>>> easily for an email address (these features can exist today, but >>>> they should be given more visibility, so end-users will use them more). >>>> ? >>>> - The end-user will be able to import/export his whitelists and >>>> blacklists using an xml format to any other upgraded email client, >>>> the blacklists and whitelists will be local (end-user will be able >>>> to pass the local whitelists and blacklists to another email client >>>> of his with the click of a button in the upgraded email client - >>>> the upgraded email client will just send them to itself - without >>>> to download them from the email server so the end-user will be able >>>> to download it with another upgraded email client - or the end-user >>>> will be able to send the whitelists and blacklists to another email >>>> address of him, the usage will not be like sending regular email >>>> message with attachments - the upgraded email clients will take >>>> care to sending and receiving of the blacklists and whitelits - in >>>> the background, these are custom formatted email messages that the >>>> two upgraded email clients will know how to act upon them). >>>> ? >>>> - The email client will be able to display with GUI with buttons >>>> any 'mailing-list registration confirmation email' in a specific >>>> section related to registration to new 'mailing list' email >>>> addresses for the end-user to choose with buttons if he accept or >>>> refuse to register to a specific 'mailing list' email address. >>>> ? >>>> - For any email message that was received: in case a received >>>> 'from' email address was found in the whitelist email addresses or >>>> in the whitelist domains - then it will be moved to the 'Inbox' >>>> folder, in case the 'from' email address of the email message was >>>> found in the blacklist email addresses or in the blacklist domains >>>> - then the email message will be moved to the 'Trash' folder. >>>> ? >>>> - In case the 'from' email address or domain was not found in the >>>> whitelists and in the blacklists, then the upgraded email client >>>> will send the 'from' email address and the 'from' domain and the >>>> current user email address and the external links that exist in the >>>> email message (but all of these data will be sent in a hashed way, >>>> and not in cleartext) with a query to NoSpam.org backend >>>> infrastructure, NoSpam.org will perform the following algorithem >>>> after it: >>>> ? >>>> - If the hashed 'from' domain (or any other 'hashed' domain from >>>> the external links) exist in a list of criminals hashed domains (of >>>> phishing/malware/viruses/etc) then NoSpam.org will respond to the >>>> email client to delete the email message, otherwise the hashed >>>> 'from' email address will be checked against a list of hashed >>>> 'mailing list' email addresses - if found then the sender is a >>>> 'mailing list' email address and there will be a check by >>>> NoSpam.org backend infrastructure if the hashed 'receiver' email >>>> address is a subscriber of that specific 'mailing list' email >>>> address , if the hashed 'receiver' was found then NoSpam.org will >>>> send a response to the email client that the email message can be >>>> displayed in the 'Inbox' folder and in the response NoSpam.org will >>>> also include an unsubscribe key - the email client will be able to >>>> display an unsubscribe button to the email client and if clicked >>>> the email client will send an https request to NoSpam.org with the >>>> specific unsubscribe key, NoSpam.org backend infrastructure will >>>> remove the end-user email address from the 'mailing list' email >>>> address and will notify the domain owner at the domain owner >>>> callback url "/nospam-notification-callback" that the specific user >>>> unsubscribed. In case the hashed 'receiver' wasn't found then >>>> NoSpam.org will respond to the email client to delete the email >>>> message and NoSpam.org will also notify the callback url of the >>>> related domain owner that he shouldn't send email messages from the >>>> specific 'mailing ?list' email address to the specific subscriber >>>> email address. >>>> ? >>>> - In case when NoSpam.org backend infrastructure searched the >>>> hashed 'from' email address and it wasn't found in the list of all >>>> hashed 'mailing list' email addresses, it mean that the email >>>> address was sent from a 'personal' email address and NoSpam.org >>>> backend infrastructure will notify the email client that the email >>>> message is from a 'personal' email address - the email client in >>>> that stage will need to decide if to move the email message to the >>>> 'Inbox' folder or to the 'Spam' folder based on the following - the >>>> email client will check if the email message include >>>> links/images/plain-url's - and if yes then the email message will >>>> be moved to the 'Spam' folder, otherwise it will be moved to the >>>> 'Inbox' folder. >>>> ? >>>> ? >>>> ? >>>> ? >>>> Whitelist Handshake: >>>> ? >>>> - In order to facilitate the adding of new email address to the >>>> local whitelist, a process of 'Whitelist Handshake' exist , a >>>> 'Whitelist Handshake' is a GUI representation in two email clients >>>> regarding background email messages between them (that the two >>>> end-users don't see), "end-user A" with a click of a button will be >>>> able to send 'add me to whitelist' request to "end-user B" which >>>> will be able to accept or deny and if accepted then "end-user B" >>>> will be able to automatically send the same "add me to whitelist" >>>> request to "end-user A" , all of this communication will be done >>>> behind the scenes, these special email messages will not be visible >>>> to the end-users, end-users will see popups with GUI that email >>>> address X is asking to be added to whitelist. In order for spammers >>>> not to abuse this option - the email client will keep only one >>>> 'whitelist request' from each requester email address (there will >>>> be a 'whitelist requests' section in the upgraded email client). A >>>> repeated 'whitelist request' that came from a specific email >>>> address can never be raised in the list (unless the end-user will >>>> specifically search for it) even when the sender will send more and >>>> more 'add me to whitelist' requests - no priority will given to >>>> them, and once an end-user refused an 'add me to whitelist' request >>>> - no new 'add me to whitelist' request will be shown from the >>>> specific sender email address in the specific email client. >>>> ? >>>> - There can be a case that an upgraded email client will send 'add >>>> me to whitelist' request to a not-upgraded email client and then >>>> the receiver will see the request as it is - as an email message in >>>> the inbox folder - due to it the content of that message will be in >>>> the language of the domain TLD of the receiver email address and >>>> the content in the email message will explain what is NoSpam.org >>>> and how to upgrade the email client and supported upgraded email >>>> clients, etc >>>> ? >>>> - In the 'whitelist requests section' in the upgraded email client >>>> - the whitelist requests will appear in a list - there should be >>>> preference so some requests will appear upper and other lower (so >>>> requests from spammers will appear lower) - whitelist requests from >>>> email addresses of domains which are older (according to their >>>> WHOIS details) will appear upper than whitelist requests from email >>>> addresses of domains which are newer. Whitelist requests from a >>>> list of a more-trusted-domains (domains of known webmails service, >>>> universities, governments, etc) will have preference over other >>>> domains, specific TLDs that not anyone can purchase will also have >>>> preference over other TLDs that anyone can purchase (upgraded email >>>> clients will retrieve the list of trusted TLD's and Domains each >>>> day from NoSpam.org backend infrastructure). >>>> ? >>>> ? >>>> Notification of spam emails: >>>> ? >>>> - An additional feature in the upgraded email client is that >>>> whenever an email message will reach the 'Spam' folder - the email >>>> client will send in the background a known-format email message to >>>> the sender and will notify him about it, if the sender is using an >>>> upgraded email client then it will be able to automatically send a >>>> 'add me to whitelist' request to the receiver in the background >>>> (once an email address is whitelisted - all the email messages from >>>> it will move from 'Spam' to 'Inbox'). >>>> ? >>>> ? >>>> ? >>>> Email Spoofing: >>>> ? >>>> - In an upgraded email client, email messages from 'personal' email >>>> addresses cannot arrive from email relay server, in case it happen >>>> the message will be deleted and the email client will send an >>>> automatic email message in the background to the sender with the >>>> text (in the language of the sender domain TLD) that email messages >>>> from 'email relay servers' cannot be received from him. >>>> ? >>>> - In an upgraded email client, email messages from 'mailing list' >>>> email addresses can arrive from email relay servers - but they must >>>> be encrypted with DKIM. >>>> ? >>>> - In an upgraded email client, the email client should check the >>>> SPF txt dns record of the sender domain, and will drop the email >>>> message if it is a spoofed email message. >>>> ? >>>> - DNS servers developers will need to make the SPF txt dns record >>>> to be a mandatory field for every domain, in order for email >>>> spoofing to be annihilated. >>>> ? >>>> ? >>>> ? >>>> Security Aspects: >>>> ? >>>> - All stored data in NoSpam.org Backend infrastructure is hashed. >>>> ? >>>> - The criminals domains list in NoSpam.org Backend Infrastructure >>>> will be managed only by regulated supervised Law Enforcement Agency >>>> (for example: Interpol) and not by an internet organization such as >>>> the RIRs or ccTLD registries. >>>> ? >>>> - Domains owners will have 'forgot password' functionality to their >>>> NoSpam.org account, the password reset link will be sent to the >>>> email address of the owner of the domain according to the domain >>>> WHOIS details. >>>> ? >>>> - Communication between email clients to NoSpam.org backend >>>> infrastructure will be over https, there will only be an handshake >>>> process in the beginning over electronic mail between email client >>>> and NoSpam.org backend infrastructure - the email client will send >>>> an email message with a chosen key to an email address of >>>> @nospam.org (that key will be used in further communication between >>>> the email client and the NoSpam.org backend infrastructure over >>>> https, it will be used for NoSpam.org backend infrastructure to >>>> identify the specific email address over https, so anyone will not >>>> be able to query NoSpam.org backend infrastructure to know which >>>> hashed email address belongs to which hashed 'mailing list' email >>>> address, besides the email client user with the right key to query >>>> NoSpam.org Backend infrastructure only on himself). >>>> ? >>>> - Any email client will download once per day 'spam-rules' file >>>> from NoSpam.org backend infrastructure, 'spam-rules' file will be >>>> an xml formatted file that include rules of when to move an email >>>> message that was received from 'personal' email address which is >>>> not whitelisted to the 'Spam' folder (for example, when email have >>>> at least 1/2/3 links, when email format is rich text or html and >>>> not plaintext, etc), in case future adjustments will be needed to >>>> win the battle against email spam - email clients will not need to >>>> be upgraded, the new 'spam-rules' will be updated in this daily file. >>>> ? >>>> ? >>>> To make it short: >>>> ? >>>> - Any email message from a subscribed mailing list / newsletter / >>>> etc - will reach to the inbox (that kind of email messages can >>>> contain any kind of content without any restrictions, because the >>>> user subscribed to it and the user can unsubscribe from it at anytime). >>>> ? >>>> - Any email message from an email address or domain in whitelist - >>>> will reach the inbox. >>>> ? >>>> - Whitelist Handshake process is easy to use and being implemented >>>> with clicks of a button, nothing to type. >>>> ? >>>> - In case an email message will the 'Spam' folder - an automatic >>>> email message will be sent from the receiver to sender and sender >>>> can automatically ask to be added to the receiver's whitelist. >>>> ? >>>> - Any email message without links/images/plain-url's (plain email >>>> messages, like electronic email was) - will reach the inbox. >>>> ? >>>> - Any other email will reach the 'Spam' folder - if needed the user >>>> will be able to easily whitelist the email message in the 'Spam' >>>> folder. >>>> ? >>>> ? >>>> ? >>>> Spammers need links in their email messages for monetization, above >>>> solution blocks it and also block criminal domains links in email >>>> message and implement email spoofing blocking at client-side. We >>>> will all stop to receive more than 100 spam email messages per day >>>> with the above solution. >>>> ? >>>> ? >>>> Respectfully, >>>> Elad >>>> >>>> _______________________________________________ >>>> members-discuss mailing list >>>> members-discuss at ripe.net >>>> https://lists.ripe.net/mailman/listinfo/members-discuss >>>> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net >>> -- >>> Unser Familien-Blog: https://brumm.family >> -- >> Unser Familien-Blog: https://brumm.family >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: >> https://lists.ripe.net/mailman/options/members-discuss/franco.tauceri%40domainregister.it > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/arnold.dech%40adct.be -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: photo_2020-04-26_20-26-31.jpg Type: image/jpeg Size: 89008 bytes Desc: not available URL: From elad at netstyle.io Sun Apr 26 20:28:53 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 18:28:53 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net>, Message-ID: It is not centralized because there are many servers with bgp anycast spread all over the world. All the data in NoSpam.org backend infrastructure is hashed. All the data which is sent between an email client to NoSpam.org backend infrastructure is hashed. Queries that the email client send to NoSpam.org backend are not logged and are not saved in any way. Currently - when you register to an online mailing list or to a newsletter - it is also centralized - and in cleartext (not hashed), so this is exactly the same - just much bigger infrastructure spread over many locations in the world with bgp anycast. Respectfully, Elad ________________________________ From: members-discuss on behalf of Aleksi Sent: Sunday, April 26, 2020 9:04 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem a centralized solution ... Yikes! Next step permits for email, only to be approved by government officials? For spam review purposes all emails must be stored centrally? Certainly no abuse will ever happen. On 4/26/20 7:50 PM, Matthias Brumm wrote: Hi! To understand correctly. You want to enforce, that every subscribe operation / e-mail client operation (get new email from server) in the world will make a bidirectional communication with a central server? Do you have an ellaborated guess, how much computing power that would need? Matthias Am 26.04.20 um 18:05 schrieb Elad Cohen: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 20:39:10 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 18:39:10 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> <8b747a3e-3b93-9c23-4003-1e9fed67a3ad@brumm.net> <32fbde974c39509a6176477ec213e337@domainregister.it>, Message-ID: Arnold, what you are doing is defamation, keep on defaming me. Respectfully, Elad ________________________________ From: members-discuss on behalf of Arnold Dechamps Sent: Sunday, April 26, 2020 9:27 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Spam... Plus the fact that this guy appears to have some link in BGP Hijacking cases... (sources : https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-address-heist-how-millions-are-made-on-the-grey-market.html) On 4/26/20 8:13 PM, Franco Tauceri wrote: In the meanwhile we're waiting for next Elad's idea to save the planet, I suggest a little move that will contribute to a little reduction of spam: is it kindly possible to remove him from this list (that, it's clear, he as no understood the goal of this list...) ? Regards -- [https://domainregister.international/templates/dr/assets/images/dr-logo.svg] Franco Tauceri DomainRegister m: 39.3483064202 w: https://DomainRegister.international e: franco.tauceri at domainregister.it On 26/04/2020 07:31 PM, Elad Cohen wrote: Hello, Ripe have 30 millions euros of expenses each year that are hidden and now shown to where exactly they are paid, instead of that corruption - a small part of the money can be used also for the deployment of IPv4+ and also for NoSpam.org and also for the next solution that I will present regarding how to dramatically lower ddos attacks, a simple and elegant solution that will help each and every ASN in the world. Respectfully, Elad ________________________________ From: Matthias Brumm Sent: Sunday, April 26, 2020 8:27 PM To: Elad Cohen ; Jetten Raymond ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hi! Maybe, but no one here is in the position to make such a project work instantly. To get it rolling, this may be easier than IPv4+. Present a working proof-of-concept with nospan.org and a Thunderbird-Plug-In. Then try to get the E-Mail-Clients on board. As long as the nospam.org servers are scalable, you can grow very fast. Matthias Am 26.04.20 um 19:20 schrieb Elad Cohen: Jetten, This is not up to you to decide. This is a membership discuss mailing list, I'm a member just like you are, please don't shut conversations and tell what we can or cannot talk about, Spam is a problem that is related to all Ripe LIR members including you. Respectfully, Elad ________________________________ From: members-discuss on behalf of Jetten Raymond Sent: Sunday, April 26, 2020 8:04 PM To: members-discuss at ripe.net ; Matthias Brumm Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem This list is NOT for technical related posts, it is for MEMBERSHIP related issues. Please move the discussion elsewhere. L?hetetty Outlook Mobilesta ________________________________ From: members-discuss on behalf of Matthias Brumm Sent: Sunday, April 26, 2020 7:50:23 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hi! To understand correctly. You want to enforce, that every subscribe operation / e-mail client operation (get new email from server) in the world will make a bidirectional communication with a central server? Do you have an ellaborated guess, how much computing power that would need? Matthias Am 26.04.20 um 18:05 schrieb Elad Cohen: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family -- Unser Familien-Blog: https://brumm.family _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/franco.tauceri%40domainregister.it _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/arnold.dech%40adct.be -------------- next part -------------- An HTML attachment was scrubbed... URL: From href at fastmail.net Sun Apr 26 21:01:55 2020 From: href at fastmail.net (href) Date: Sun, 26 Apr 2020 21:01:55 +0200 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <2fad3198-4fcc-4783-98ed-cbb2cc0a30de@www.fastmail.com> Message-ID: <7a5af760-42ca-b807-6f40-b791fa4b6c39@fastmail.net> Elad, Some members sent some additional information about you: I can now understand your replies: I had no idea that you may have been involved in the Cape Town hijack! Please forget about my badly chosen example. Accusations aside, it is time to get serious and I'll re-iterate my original question: what are your thoughts and technical solutions about IP hijacking (not the Cape town one) ? On 4/26/20 8:23 PM, Elad Cohen wrote: > Jordan, > > What you are writing is false, telling a lie again and again will not > make it truth. > > "if I remember that there was some IP space from Cape Town city that > got hijacked" - I'll be happy if you can also remember a single proof > for it and to display it here now ? (I mean a proof - not an employee > of of a direct competitor which is also a member of the illegal > anonymous organization "The Spamhaus Project" and also the owner of > that illegal anonymous twitter account: > https://twitter.com/underthebreach > ? - he is also a cyber influence > master according to himself - it means that he is a master in telling > lies and creating a fake story without a single proof in order to > influence public opinion - exactly like what you are doing now) > > And yes, I did found a technical solution for your criminals at "The > Spamhaus Project" that there are many complaints about them worldwide > - and the Law Enforcement Agencies are doing nothing regarding them > only because they illegaly share (without any warrant) on a regular > basis and in a systematic way massive amount of illegaly-obtained > privacy data of internet users with the Law Enforcement Agencies as > you can see that they wrote on themselves in their own words in the > following link: > > https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation > > "The Spamhaus Project" mob friends just like you are very very afraid > from me according to their attention to me - and they are afraid from > me because I cannot be bought, because what they are doing is illegal, > because I will keep saying it loudly again and again and again. > > ---- > > Can you show a single proof to what you are writing? You are taking > part in an illegal cyber influence operation against me. > > Respectfully, > Elad > > ------------------------------------------------------------------------ > *From:* Jordan Bracco > *Sent:* Sunday, April 26, 2020 9:14 PM > *To:* Elad Cohen ; members-discuss at ripe.net > > *Subject:* Re: [members-discuss] Technical Solution to resolve the > global "Email Spam" problem > ? > Elad, > > I do not see what you mean by "telling a lie again and again". I have > a vague memory of something fishy going on with a Cape Town ip block, > but there was many occurences like this. I cited Cape Town as an > example. I do not have proof, so maybe the Cape Town is a false > memory, but IP hijacking (which was the subject of my email, not Cape > Town) surely do happen. > > For the rest of your reply-- I just simply do not understand it. > > ?- I fail to see a correlation between hijacking IP space and > Spamhaus. Could you please enlighten me ? > ?- I also fail to understand what you mean by "mob friends just like > you". I have no relationship whatsoever with SpamHaus, I do not use > their DNSBLs (as I delegate most of my emails to Fastmail). > > I was just asking for your thoughts and technical solutions to IP > space hijacking. Your reply turned into a rant about Spamhaus (?) and > accusing me of being "mob friend" of it (?) ? > > On Sun, Apr 26, 2020, at 19:46, Elad Cohen wrote: >> Jordan, >> >> What you are writing is false, telling a lie again and again will not >> make it truth. >> >> "if I remember that there was some IP space from Cape Town city that >> got hijacked" - I'll be happy if you can also remember a single proof >> for it and to display it here now ? (I mean a proof - not an employee >> of of a direct competitor which is also a member of the illegal >> anonymous organization "The Spamhaus Project" and also the owner of >> that illegal anonymous twitter account: >> https://twitter.com/underthebreach? - he is also a cyber influence >> master according to himself - it means that he is a master in telling >> lies and creating a fake story without a single proof in order to >> influence public opinion - exactly like what you are doing now) >> >> And yes, I did found a technical solution for your criminals at "The >> Spamhaus Project" that there are many complaints about them worldwide >> - and the Law Enforcement Agencies are doing nothing regarding them >> only because they illegaly share (without any warrant) on a regular >> basis and in a systematic way massive amount of illegaly-obtained >> privacy data of internet users with the Law Enforcement Agencies as >> you can see that they wrote on themselves in their own words in the >> following link: >> >> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >> >> "The Spamhaus Project" mob friends just like you are very very afraid >> from me according to their attention to me - and they are afraid from >> me because I cannot be bought, because what they are doing is >> illegal, because I will keep saying it loudly again and again and again. >> >> Respectfully, >> Elad >> >> >> ------------------------------------------------------------------------ >> >> *From:* members-discuss on behalf >> of Jordan Bracco >> *Sent:* Sunday, April 26, 2020 8:23 PM >> *To:* members-discuss at ripe.net >> *Subject:* Re: [members-discuss] Technical Solution to resolve the >> global "Email Spam" problem >> ? >> Dear Elad, >> >> Unrelated to the spam proposal-- but have you found a technical >> solution to avoid malicious third parties to hijack assigned IP space >> (for example, if I remember that there was some IP space from Cape >> Town city that got hijacked). What are you thoughts on this, and your >> technical solution to it ? >> >> >> On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: >>> Hello Everyone, >>> >>> I want to share with you my technical solution to resolve the global >>> world "Email Spam" problem and in addition it will also resolve the >>> spreading of illegal links (phishing/malware/etc , once the sites >>> are known) through electronic mail and will stop email spoofing >>> (that part using current technologies). >>> >>> Email spam problem was not being able to be defeated since the >>> beginning of electronic mail, as long as email spam will be >>> profitable to email spammers - it will exist, email spam caused the >>> illegal anonymous organization "The Spamhaus Project" to exist, "The >>> Spamhaus Project" is hurting and damaging many businesses worldwide >>> in their way to fight email spam, "The Spamhaus Project" is an >>> illegal anonymous organization according to the following >>> presentation that they wrote on themselves, they are violating laws >>> in their way to fight email spam and still they don't win in the >>> battle against email spam. "The Spamhaus Project" is keeping their >>> anonymity because they are afriad of justified lawsuits due to their >>> criminal actions in their way to fight email spam. The following >>> technical solution will resolve the world email spam problem without >>> to hurt and to damage many businesses worldwide that have nothing to >>> do with email spam like "The Spamhaus Project" does, the following >>> implementation can remove the need for an illegal anonymous >>> organization such as "The Spamhaus Project". >>> >>> >>> The presentation that the illegal anonymous organization "The >>> Spamhaus Project" wrote on themselves: >>> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >>> >>> >>> >>> The Implementation: >>> >>> There will be a site (lets call it NoSpam.org) - the site will be >>> owned by the 5 RIRs, the site will use bgp anycast and will be >>> deployed in each of the 5 RIRs (the site will also be able to be >>> deployed by the ccTLD registries in each country), the site in all >>> the locations will be synced automatically. >>> >>> Each domain owner will be able to register at the site (an email >>> message will be sent to the domain owner email address in the domain >>> name WHOIS details in order to verify that the domain owner is the >>> one registering). >>> >>> After being logged in, a domain owner will be able to add his email >>> addresses (of the specific domain name) that will be used to send >>> newsletters / mailing lists / one-to-many email messages, lets call >>> these kind of email addresses as 'mailing list' email addresses. The >>> domain owner will not be able to see the list of 'mailing list' >>> email addresses that he added - because when he added each 'mailing >>> list' email address it will be saved with hash in the NoSpam.org >>> backend infrastructure (due to privacy and security reasons) - hence >>> only if the domain owner will manually type the 'mailing list' email >>> address he will be able to enter it in order to manage it (to see >>> the total number of subscribers email addresses, to see the >>> subscribers email addresses but only with their hashes due to >>> security and privacy reasons, to remove a subscriber from the list, >>> to add a sub-user with permissions to manage that specific 'mailing >>> list' email address). >>> >>> In his site, the domain owner will be able to integrate an iframe >>> from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a >>> subscriber registration form to his specific 'mailing list' email >>> address, the subscriber will receive an email message with a link to >>> confirm his subscription. >>> >>> The domain owner will need to create a callback file in his website, >>> for example in the path: "/nospam-notification-callback" >>> (http://example.com/nospam-notification-callback) - that url will >>> receive encrypted post notifications (encryption key will be >>> provided by the domain owner in his NoSpam.org logged in account) >>> from NoSpam.org regarding any new end-user that will subscribe or >>> that will unsubscribe from a 'mailing address' email address which >>> is related to the domain of the domain owner (unsubscribe >>> functionality by the user later below). >>> >>> The subscriber email address and that 'mailing list' email address >>> (that was subscribed to) will be sent by NoSpam.org to >>> "/nospam-notification-callback" not in the hashed format but in >>> cleartext (so the domain owner will be able to save it in his system >>> for future email messages from the specific 'mailing list' email >>> address to the specific subscriber email address). >>> >>> The domain owner will also have an API to NoSpam.org backend >>> infrastructure in order to remove a specific subscriber email >>> address from a specific 'mailing list' email address (the domains >>> owner will send the values through the API - hashed). >>> >>> The domain owner will also provide a web interface in his site for >>> the end-user to remove himself from the specific 'mailing list' >>> email address. >>> >>> >>> >>> The above is the backend implementation (no upgrade is needed to any >>> email server in the internet), the following is the upgrade that >>> will needed for any email client (that upgrade is not mandatory, >>> without the following upgrade the email client will work exactly as >>> it is now without the added no-spam features, electronic mail will >>> not break if some email users will upgrade their email clients and >>> some will not): >>> >>> - There will not be 'mark as spam' button, that kind of >>> functionality will stop to exist because spam is not a boolean >>> value, 'spam' to one person is valuable to another 'person', >>> specially when the internet is global and different people from >>> different countries will consider spam content differently. One user >>> can consider an email message as spam and another user can consider >>> the same message as not spam, 'Spam' is subjective and any kind of >>> 'mark as spam' functionality is useless in the battle against email >>> spam. >>> >>> - There will be blacklists and whitelists (just like there are now, >>> but they will be more prominent): blacklist email addresses , >>> blacklist domains , whitelist email addresses , whitelist domains. >>> >>> - The end-user should be able to easily enter each email message to >>> whitelist or to blacklist (meaning the 'from' email address of the >>> email message), and will be able to search in the 'Spam' folder >>> easily for an email address (these features can exist today, but >>> they should be given more visibility, so end-users will use them more). >>> >>> - The end-user will be able to import/export his whitelists and >>> blacklists using an xml format to any other upgraded email client, >>> the blacklists and whitelists will be local (end-user will be able >>> to pass the local whitelists and blacklists to another email client >>> of his with the click of a button in the upgraded email client - the >>> upgraded email client will just send them to itself - without to >>> download them from the email server so the end-user will be able to >>> download it with another upgraded email client - or the end-user >>> will be able to send the whitelists and blacklists to another email >>> address of him, the usage will not be like sending regular email >>> message with attachments - the upgraded email clients will take care >>> to sending and receiving of the blacklists and whitelits - in the >>> background, these are custom formatted email messages that the two >>> upgraded email clients will know how to act upon them). >>> >>> - The email client will be able to display with GUI with buttons any >>> 'mailing-list registration confirmation email' in a specific section >>> related to registration to new 'mailing list' email addresses for >>> the end-user to choose with buttons if he accept or refuse to >>> register to a specific 'mailing list' email address. >>> >>> - For any email message that was received: in case a received 'from' >>> email address was found in the whitelist email addresses or in the >>> whitelist domains - then it will be moved to the 'Inbox' folder, in >>> case the 'from' email address of the email message was found in the >>> blacklist email addresses or in the blacklist domains - then the >>> email message will be moved to the 'Trash' folder. >>> >>> - In case the 'from' email address or domain was not found in the >>> whitelists and in the blacklists, then the upgraded email client >>> will send the 'from' email address and the 'from' domain and the >>> current user email address and the external links that exist in the >>> email message (but all of these data will be sent in a hashed way, >>> and not in cleartext) with a query to NoSpam.org backend >>> infrastructure, NoSpam.org will perform the following algorithem >>> after it: >>> >>> - If the hashed 'from' domain (or any other 'hashed' domain from the >>> external links) exist in a list of criminals hashed domains (of >>> phishing/malware/viruses/etc) then NoSpam.org will respond to the >>> email client to delete the email message, otherwise the hashed >>> 'from' email address will be checked against a list of hashed >>> 'mailing list' email addresses - if found then the sender is a >>> 'mailing list' email address and there will be a check by NoSpam.org >>> backend infrastructure if the hashed 'receiver' email address is a >>> subscriber of that specific 'mailing list' email address , if the >>> hashed 'receiver' was found then NoSpam.org will send a response to >>> the email client that the email message can be displayed in the >>> 'Inbox' folder and in the response NoSpam.org will also include an >>> unsubscribe key - the email client will be able to display an >>> unsubscribe button to the email client and if clicked the email >>> client will send an https request to NoSpam.org with the specific >>> unsubscribe key, NoSpam.org backend infrastructure will remove the >>> end-user email address from the 'mailing list' email address and >>> will notify the domain owner at the domain owner callback url >>> "/nospam-notification-callback" that the specific user unsubscribed. >>> In case the hashed 'receiver' wasn't found then NoSpam.org will >>> respond to the email client to delete the email message and >>> NoSpam.org will also notify the callback url of the related domain >>> owner that he shouldn't send email messages from the specific >>> 'mailing ?list' email address to the specific subscriber email address. >>> >>> - In case when NoSpam.org backend infrastructure searched the hashed >>> 'from' email address and it wasn't found in the list of all hashed >>> 'mailing list' email addresses, it mean that the email address was >>> sent from a 'personal' email address and NoSpam.org backend >>> infrastructure will notify the email client that the email message >>> is from a 'personal' email address - the email client in that stage >>> will need to decide if to move the email message to the 'Inbox' >>> folder or to the 'Spam' folder based on the following - the email >>> client will check if the email message include >>> links/images/plain-url's - and if yes then the email message will be >>> moved to the 'Spam' folder, otherwise it will be moved to the >>> 'Inbox' folder. >>> >>> >>> >>> >>> Whitelist Handshake: >>> >>> - In order to facilitate the adding of new email address to the >>> local whitelist, a process of 'Whitelist Handshake' exist , a >>> 'Whitelist Handshake' is a GUI representation in two email clients >>> regarding background email messages between them (that the two >>> end-users don't see), "end-user A" with a click of a button will be >>> able to send 'add me to whitelist' request to "end-user B" which >>> will be able to accept or deny and if accepted then "end-user B" >>> will be able to automatically send the same "add me to whitelist" >>> request to "end-user A" , all of this communication will be done >>> behind the scenes, these special email messages will not be visible >>> to the end-users, end-users will see popups with GUI that email >>> address X is asking to be added to whitelist. In order for spammers >>> not to abuse this option - the email client will keep only one >>> 'whitelist request' from each requester email address (there will be >>> a 'whitelist requests' section in the upgraded email client). A >>> repeated 'whitelist request' that came from a specific email address >>> can never be raised in the list (unless the end-user will >>> specifically search for it) even when the sender will send more and >>> more 'add me to whitelist' requests - no priority will given to >>> them, and once an end-user refused an 'add me to whitelist' request >>> - no new 'add me to whitelist' request will be shown from the >>> specific sender email address in the specific email client. >>> >>> - There can be a case that an upgraded email client will send 'add >>> me to whitelist' request to a not-upgraded email client and then the >>> receiver will see the request as it is - as an email message in the >>> inbox folder - due to it the content of that message will be in the >>> language of the domain TLD of the receiver email address and the >>> content in the email message will explain what is NoSpam.org and how >>> to upgrade the email client and supported upgraded email clients, etc >>> >>> - In the 'whitelist requests section' in the upgraded email client - >>> the whitelist requests will appear in a list - there should be >>> preference so some requests will appear upper and other lower (so >>> requests from spammers will appear lower) - whitelist requests from >>> email addresses of domains which are older (according to their WHOIS >>> details) will appear upper than whitelist requests from email >>> addresses of domains which are newer. Whitelist requests from a list >>> of a more-trusted-domains (domains of known webmails service, >>> universities, governments, etc) will have preference over other >>> domains, specific TLDs that not anyone can purchase will also have >>> preference over other TLDs that anyone can purchase (upgraded email >>> clients will retrieve the list of trusted TLD's and Domains each day >>> from NoSpam.org backend infrastructure). >>> >>> >>> Notification of spam emails: >>> >>> - An additional feature in the upgraded email client is that >>> whenever an email message will reach the 'Spam' folder - the email >>> client will send in the background a known-format email message to >>> the sender and will notify him about it, if the sender is using an >>> upgraded email client then it will be able to automatically send a >>> 'add me to whitelist' request to the receiver in the background >>> (once an email address is whitelisted - all the email messages from >>> it will move from 'Spam' to 'Inbox'). >>> >>> >>> >>> Email Spoofing: >>> >>> - In an upgraded email client, email messages from 'personal' email >>> addresses cannot arrive from email relay server, in case it happen >>> the message will be deleted and the email client will send an >>> automatic email message in the background to the sender with the >>> text (in the language of the sender domain TLD) that email messages >>> from 'email relay servers' cannot be received from him. >>> >>> - In an upgraded email client, email messages from 'mailing list' >>> email addresses can arrive from email relay servers - but they must >>> be encrypted with DKIM. >>> >>> - In an upgraded email client, the email client should check the SPF >>> txt dns record of the sender domain, and will drop the email message >>> if it is a spoofed email message. >>> >>> - DNS servers developers will need to make the SPF txt dns record to >>> be a mandatory field for every domain, in order for email spoofing >>> to be annihilated. >>> >>> >>> >>> Security Aspects: >>> >>> - All stored data in NoSpam.org Backend infrastructure is hashed. >>> >>> - The criminals domains list in NoSpam.org Backend Infrastructure >>> will be managed only by regulated supervised Law Enforcement Agency >>> (for example: Interpol) and not by an internet organization such as >>> the RIRs or ccTLD registries. >>> >>> - Domains owners will have 'forgot password' functionality to their >>> NoSpam.org account, the password reset link will be sent to the >>> email address of the owner of the domain according to the domain >>> WHOIS details. >>> >>> - Communication between email clients to NoSpam.org backend >>> infrastructure will be over https, there will only be an handshake >>> process in the beginning over electronic mail between email client >>> and NoSpam.org backend infrastructure - the email client will send >>> an email message with a chosen key to an email address of >>> @nospam.org (that key will be used in further communication between >>> the email client and the NoSpam.org backend infrastructure over >>> https, it will be used for NoSpam.org backend infrastructure to >>> identify the specific email address over https, so anyone will not >>> be able to query NoSpam.org backend infrastructure to know which >>> hashed email address belongs to which hashed 'mailing list' email >>> address, besides the email client user with the right key to query >>> NoSpam.org Backend infrastructure only on himself). >>> >>> - Any email client will download once per day 'spam-rules' file from >>> NoSpam.org backend infrastructure, 'spam-rules' file will be an xml >>> formatted file that include rules of when to move an email message >>> that was received from 'personal' email address which is not >>> whitelisted to the 'Spam' folder (for example, when email have at >>> least 1/2/3 links, when email format is rich text or html and not >>> plaintext, etc), in case future adjustments will be needed to win >>> the battle against email spam - email clients will not need to be >>> upgraded, the new 'spam-rules' will be updated in this daily file. >>> >>> >>> To make it short: >>> >>> - Any email message from a subscribed mailing list / newsletter / >>> etc - will reach to the inbox (that kind of email messages can >>> contain any kind of content without any restrictions, because the >>> user subscribed to it and the user can unsubscribe from it at anytime). >>> >>> - Any email message from an email address or domain in whitelist - >>> will reach the inbox. >>> >>> - Whitelist Handshake process is easy to use and being implemented >>> with clicks of a button, nothing to type. >>> >>> - In case an email message will the 'Spam' folder - an automatic >>> email message will be sent from the receiver to sender and sender >>> can automatically ask to be added to the receiver's whitelist. >>> >>> - Any email message without links/images/plain-url's (plain email >>> messages, like electronic email was) - will reach the inbox. >>> >>> - Any other email will reach the 'Spam' folder - if needed the user >>> will be able to easily whitelist the email message in the 'Spam' folder. >>> >>> >>> >>> Spammers need links in their email messages for monetization, above >>> solution blocks it and also block criminal domains links in email >>> message and implement email spoofing blocking at client-side. We >>> will all stop to receive more than 100 spam email messages per day >>> with the above solution. >>> >>> >>> Respectfully, >>> Elad >>> >>> _______________________________________________ >>> members-discuss mailing list >>> members-discuss at ripe.net >>> https://lists.ripe.net/mailman/listinfo/members-discuss >>> Unsubscribe: >>> https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 21:09:09 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 19:09:09 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <7a5af760-42ca-b807-6f40-b791fa4b6c39@fastmail.net> References: <2fad3198-4fcc-4783-98ed-cbb2cc0a30de@www.fastmail.com> , <7a5af760-42ca-b807-6f40-b791fa4b6c39@fastmail.net> Message-ID: "I had no idea that you may have been involved in the Cape Town hijack!" The cyber influence operation continue... complete lies without a single proof, can anyone show a single proof ? Are you so scared from me being elected ? that you need to spread lies ? I'm highly honored that the illegal anonymous organization "The Spamhaus Project" decided to attack me, it means a lot. Lets see who is the Spamhaus fan that will jump now. Respectfully, Elad ________________________________ From: href Sent: Sunday, April 26, 2020 10:01 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad, Some members sent some additional information about you: I can now understand your replies: I had no idea that you may have been involved in the Cape Town hijack! Please forget about my badly chosen example. Accusations aside, it is time to get serious and I'll re-iterate my original question: what are your thoughts and technical solutions about IP hijacking (not the Cape town one) ? On 4/26/20 8:23 PM, Elad Cohen wrote: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. ---- Can you show a single proof to what you are writing? You are taking part in an illegal cyber influence operation against me. Respectfully, Elad ________________________________ From: Jordan Bracco Sent: Sunday, April 26, 2020 9:14 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad, I do not see what you mean by "telling a lie again and again". I have a vague memory of something fishy going on with a Cape Town ip block, but there was many occurences like this. I cited Cape Town as an example. I do not have proof, so maybe the Cape Town is a false memory, but IP hijacking (which was the subject of my email, not Cape Town) surely do happen. For the rest of your reply-- I just simply do not understand it. - I fail to see a correlation between hijacking IP space and Spamhaus. Could you please enlighten me ? - I also fail to understand what you mean by "mob friends just like you". I have no relationship whatsoever with SpamHaus, I do not use their DNSBLs (as I delegate most of my emails to Fastmail). I was just asking for your thoughts and technical solutions to IP space hijacking. Your reply turned into a rant about Spamhaus (?) and accusing me of being "mob friend" of it (?) ? On Sun, Apr 26, 2020, at 19:46, Elad Cohen wrote: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. Respectfully, Elad ________________________________ From: members-discuss on behalf of Jordan Bracco Sent: Sunday, April 26, 2020 8:23 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Dear Elad, Unrelated to the spam proposal-- but have you found a technical solution to avoid malicious third parties to hijack assigned IP space (for example, if I remember that there was some IP space from Cape Town city that got hijacked). What are you thoughts on this, and your technical solution to it ? On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsb at orbital.net Sun Apr 26 21:13:01 2020 From: dsb at orbital.net (Darren Brown) Date: Sun, 26 Apr 2020 19:13:01 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <2fad3198-4fcc-4783-98ed-cbb2cc0a30de@www.fastmail.com> , <7a5af760-42ca-b807-6f40-b791fa4b6c39@fastmail.net>, Message-ID: Elad it's great you have so many ideas but this is getting a bit silly now, go and take a break , have a drink and put in a film. It's Sunday evening , chill out Regards Darren Get Outlook for iOS ________________________________ From: members-discuss on behalf of Elad Cohen Sent: Sunday, April 26, 2020 8:09:09 PM To: href ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem "I had no idea that you may have been involved in the Cape Town hijack!" The cyber influence operation continue... complete lies without a single proof, can anyone show a single proof ? Are you so scared from me being elected ? that you need to spread lies ? I'm highly honored that the illegal anonymous organization "The Spamhaus Project" decided to attack me, it means a lot. Lets see who is the Spamhaus fan that will jump now. Respectfully, Elad ________________________________ From: href Sent: Sunday, April 26, 2020 10:01 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad, Some members sent some additional information about you: I can now understand your replies: I had no idea that you may have been involved in the Cape Town hijack! Please forget about my badly chosen example. Accusations aside, it is time to get serious and I'll re-iterate my original question: what are your thoughts and technical solutions about IP hijacking (not the Cape town one) ? On 4/26/20 8:23 PM, Elad Cohen wrote: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. ---- Can you show a single proof to what you are writing? You are taking part in an illegal cyber influence operation against me. Respectfully, Elad ________________________________ From: Jordan Bracco Sent: Sunday, April 26, 2020 9:14 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad, I do not see what you mean by "telling a lie again and again". I have a vague memory of something fishy going on with a Cape Town ip block, but there was many occurences like this. I cited Cape Town as an example. I do not have proof, so maybe the Cape Town is a false memory, but IP hijacking (which was the subject of my email, not Cape Town) surely do happen. For the rest of your reply-- I just simply do not understand it. - I fail to see a correlation between hijacking IP space and Spamhaus. Could you please enlighten me ? - I also fail to understand what you mean by "mob friends just like you". I have no relationship whatsoever with SpamHaus, I do not use their DNSBLs (as I delegate most of my emails to Fastmail). I was just asking for your thoughts and technical solutions to IP space hijacking. Your reply turned into a rant about Spamhaus (?) and accusing me of being "mob friend" of it (?) ? On Sun, Apr 26, 2020, at 19:46, Elad Cohen wrote: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. Respectfully, Elad ________________________________ From: members-discuss on behalf of Jordan Bracco Sent: Sunday, April 26, 2020 8:23 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Dear Elad, Unrelated to the spam proposal-- but have you found a technical solution to avoid malicious third parties to hijack assigned IP space (for example, if I remember that there was some IP space from Cape Town city that got hijacked). What are you thoughts on this, and your technical solution to it ? On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 21:15:23 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 19:15:23 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <2fad3198-4fcc-4783-98ed-cbb2cc0a30de@www.fastmail.com> , <7a5af760-42ca-b807-6f40-b791fa4b6c39@fastmail.net>, , Message-ID: If the Spamhaus fans will be quiet in their corner then tomorrow will be the last technical solution. Respectfully, Elad ________________________________ From: Darren Brown Sent: Sunday, April 26, 2020 10:13 PM To: Elad Cohen ; href ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad it?s great you have so many ideas but this is getting a bit silly now, go and take a break , have a drink and put in a film. It?s Sunday evening , chill out Regards Darren Get Outlook for iOS ________________________________ From: members-discuss on behalf of Elad Cohen Sent: Sunday, April 26, 2020 8:09:09 PM To: href ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem "I had no idea that you may have been involved in the Cape Town hijack!" The cyber influence operation continue... complete lies without a single proof, can anyone show a single proof ? Are you so scared from me being elected ? that you need to spread lies ? I'm highly honored that the illegal anonymous organization "The Spamhaus Project" decided to attack me, it means a lot. Lets see who is the Spamhaus fan that will jump now. Respectfully, Elad ________________________________ From: href Sent: Sunday, April 26, 2020 10:01 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad, Some members sent some additional information about you: I can now understand your replies: I had no idea that you may have been involved in the Cape Town hijack! Please forget about my badly chosen example. Accusations aside, it is time to get serious and I'll re-iterate my original question: what are your thoughts and technical solutions about IP hijacking (not the Cape town one) ? On 4/26/20 8:23 PM, Elad Cohen wrote: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. ---- Can you show a single proof to what you are writing? You are taking part in an illegal cyber influence operation against me. Respectfully, Elad ________________________________ From: Jordan Bracco Sent: Sunday, April 26, 2020 9:14 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad, I do not see what you mean by "telling a lie again and again". I have a vague memory of something fishy going on with a Cape Town ip block, but there was many occurences like this. I cited Cape Town as an example. I do not have proof, so maybe the Cape Town is a false memory, but IP hijacking (which was the subject of my email, not Cape Town) surely do happen. For the rest of your reply-- I just simply do not understand it. - I fail to see a correlation between hijacking IP space and Spamhaus. Could you please enlighten me ? - I also fail to understand what you mean by "mob friends just like you". I have no relationship whatsoever with SpamHaus, I do not use their DNSBLs (as I delegate most of my emails to Fastmail). I was just asking for your thoughts and technical solutions to IP space hijacking. Your reply turned into a rant about Spamhaus (?) and accusing me of being "mob friend" of it (?) ? On Sun, Apr 26, 2020, at 19:46, Elad Cohen wrote: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. Respectfully, Elad ________________________________ From: members-discuss on behalf of Jordan Bracco Sent: Sunday, April 26, 2020 8:23 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Dear Elad, Unrelated to the spam proposal-- but have you found a technical solution to avoid malicious third parties to hijack assigned IP space (for example, if I remember that there was some IP space from Cape Town city that got hijacked). What are you thoughts on this, and your technical solution to it ? On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvan at unavailable.online Sun Apr 26 21:31:01 2020 From: silvan at unavailable.online (Silvan Gebhardt) Date: Sun, 26 Apr 2020 19:31:01 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <2fad3198-4fcc-4783-98ed-cbb2cc0a30de@www.fastmail.com> <7a5af760-42ca-b807-6f40-b791fa4b6c39@fastmail.net> Message-ID: Hi Elad, it's me again, one of your favourite illegals. You are a candidate for the Board of RIPE. as a RIPE board member you should be able to actually have a discussion with people, to engage in disputes in a constructive way, instead you instantly pick a fight, and try to fight everyone who does not agree with your points. You ask that Members here -? which are most likely other members of LIRS which have as much a right to state their opinion, "stay quiet" - or you suggest to remove them from the mailinglist. This clearly does not look good for you, Elad - leave the accusations away, you are definitely not displaying any leadership qualities which would be required as board of RIPE. So, accusations against you, you ask for proof. You yourself state accusations against RIPE Board ("corruption") but you do not provide any proof. All I can see is a guy, who tries to get elected because he really desperately needs something in his CV, and because the chances might be thin (you haven't even bothered to bring any CV or something up, while at least 3 candidates actually put in the effort so we can judge what they have done in the past. You share nothing of your past, what you have done, where you have participated. instead you try to push your campaign by pushing your own ideas on an unsuitable platform. I agree that "even bad publicity can be some publicity" - but it will not help you on your election because at this rate, the only vote you get is your own word. I know you will find again great words to reply, it will greatly amuse me. trust me, if you start picking fights with everyone, people will start digging and open up a case with the arbiter under clause *1.2.1.1 section 2 * On 4/26/20 7:15 PM, Elad Cohen wrote: > If the Spamhaus fans will be quiet in their corner then tomorrow will > be the last technical solution. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* Darren Brown > *Sent:* Sunday, April 26, 2020 10:13 PM > *To:* Elad Cohen ; href ; > members-discuss at ripe.net > *Subject:* Re: [members-discuss] Technical Solution to resolve the > global "Email Spam" problem > ? > Elad it?s great you have so many ideas but this is getting a bit silly > now, go and take a break , have a drink and put in a film. It?s Sunday > evening , chill out > > Regards > Darren > > Get Outlook for iOS > ------------------------------------------------------------------------ > *From:* members-discuss on behalf > of Elad Cohen > *Sent:* Sunday, April 26, 2020 8:09:09 PM > *To:* href ; members-discuss at ripe.net > > *Subject:* Re: [members-discuss] Technical Solution to resolve the > global "Email Spam" problem > ? > "I had no idea that you may have been involved in the Cape Town hijack!" > > The cyber influence operation continue... complete lies without a > single proof, can anyone show a single proof ? > > Are you so scared from me being elected ? that you need to spread lies ? > > I'm highly honored that the illegal anonymous organization "The > Spamhaus Project" decided to attack me, it means a lot. > > Lets see who is the Spamhaus fan that will jump now. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* href > *Sent:* Sunday, April 26, 2020 10:01 PM > *To:* Elad Cohen ; members-discuss at ripe.net > > *Subject:* Re: [members-discuss] Technical Solution to resolve the > global "Email Spam" problem > ? > > Elad, > > > Some members sent some additional information about you: I can now > understand your replies: I had no idea that you may have been involved > in the Cape Town hijack! > > > Please forget about my badly chosen example. Accusations aside, it is > time to get serious and I'll re-iterate my original question: what are > your thoughts and technical solutions about IP hijacking (not the Cape > town one) ? > > > > On 4/26/20 8:23 PM, Elad Cohen wrote: >> Jordan, >> >> What you are writing is false, telling a lie again and again will not >> make it truth. >> >> "if I remember that there was some IP space from Cape Town city that >> got hijacked" - I'll be happy if you can also remember a single proof >> for it and to display it here now ? (I mean a proof - not an employee >> of of a direct competitor which is also a member of the illegal >> anonymous organization "The Spamhaus Project" and also the owner of >> that illegal anonymous twitter account: >> https://twitter.com/underthebreach >> ? - he is also a cyber influence >> master according to himself - it means that he is a master in telling >> lies and creating a fake story without a single proof in order to >> influence public opinion - exactly like what you are doing now) >> >> And yes, I did found a technical solution for your criminals at "The >> Spamhaus Project" that there are many complaints about them worldwide >> - and the Law Enforcement Agencies are doing nothing regarding them >> only because they illegaly share (without any warrant) on a regular >> basis and in a systematic way massive amount of illegaly-obtained >> privacy data of internet users with the Law Enforcement Agencies as >> you can see that they wrote on themselves in their own words in the >> following link: >> >> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >> >> "The Spamhaus Project" mob friends just like you are very very afraid >> from me according to their attention to me - and they are afraid from >> me because I cannot be bought, because what they are doing is >> illegal, because I will keep saying it loudly again and again and again. >> >> ---- >> >> Can you show a single proof to what you are writing? You are taking >> part in an illegal cyber influence operation against me. >> >> Respectfully, >> Elad >> >> ------------------------------------------------------------------------ >> *From:* Jordan Bracco >> *Sent:* Sunday, April 26, 2020 9:14 PM >> *To:* Elad Cohen ; >> members-discuss at ripe.net >> >> *Subject:* Re: [members-discuss] Technical Solution to resolve the >> global "Email Spam" problem >> ? >> Elad, >> >> I do not see what you mean by "telling a lie again and again". I have >> a vague memory of something fishy going on with a Cape Town ip block, >> but there was many occurences like this. I cited Cape Town as an >> example. I do not have proof, so maybe the Cape Town is a false >> memory, but IP hijacking (which was the subject of my email, not Cape >> Town) surely do happen. >> >> For the rest of your reply-- I just simply do not understand it. >> >> ?- I fail to see a correlation between hijacking IP space and >> Spamhaus. Could you please enlighten me ? >> ?- I also fail to understand what you mean by "mob friends just like >> you". I have no relationship whatsoever with SpamHaus, I do not use >> their DNSBLs (as I delegate most of my emails to Fastmail). >> >> I was just asking for your thoughts and technical solutions to IP >> space hijacking. Your reply turned into a rant about Spamhaus (?) and >> accusing me of being "mob friend" of it (?) ? >> >> On Sun, Apr 26, 2020, at 19:46, Elad Cohen wrote: >>> Jordan, >>> >>> What you are writing is false, telling a lie again and again will >>> not make it truth. >>> >>> "if I remember that there was some IP space from Cape Town city that >>> got hijacked" - I'll be happy if you can also remember a single >>> proof for it and to display it here now ? (I mean a proof - not an >>> employee of of a direct competitor which is also a member of the >>> illegal anonymous organization "The Spamhaus Project" and also the >>> owner of that illegal anonymous twitter account: >>> https://twitter.com/underthebreach? - he is also a cyber influence >>> master according to himself - it means that he is a master in >>> telling lies and creating a fake story without a single proof in >>> order to influence public opinion - exactly like what you are doing now) >>> >>> And yes, I did found a technical solution for your criminals at "The >>> Spamhaus Project" that there are many complaints about them >>> worldwide - and the Law Enforcement Agencies are doing nothing >>> regarding them only because they illegaly share (without any >>> warrant) on a regular basis and in a systematic way massive amount >>> of illegaly-obtained privacy data of internet users with the Law >>> Enforcement Agencies as you can see that they wrote on themselves in >>> their own words in the following link: >>> >>> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >>> >>> "The Spamhaus Project" mob friends just like you are very very >>> afraid from me according to their attention to me - and they are >>> afraid from me because I cannot be bought, because what they are >>> doing is illegal, because I will keep saying it loudly again and >>> again and again. >>> >>> Respectfully, >>> Elad >>> >>> >>> ------------------------------------------------------------------------ >>> >>> *From:* members-discuss >>> on behalf of Jordan Bracco >>> >>> *Sent:* Sunday, April 26, 2020 8:23 PM >>> *To:* members-discuss at ripe.net >>> >>> *Subject:* Re: [members-discuss] Technical Solution to resolve the >>> global "Email Spam" problem >>> ? >>> Dear Elad, >>> >>> Unrelated to the spam proposal-- but have you found a technical >>> solution to avoid malicious third parties to hijack assigned IP >>> space (for example, if I remember that there was some IP space from >>> Cape Town city that got hijacked). What are you thoughts on this, >>> and your technical solution to it ? >>> >>> >>> On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: >>>> Hello Everyone, >>>> >>>> I want to share with you my technical solution to resolve the >>>> global world "Email Spam" problem and in addition it will also >>>> resolve the spreading of illegal links (phishing/malware/etc , once >>>> the sites are known) through electronic mail and will stop email >>>> spoofing (that part using current technologies). >>>> >>>> Email spam problem was not being able to be defeated since the >>>> beginning of electronic mail, as long as email spam will be >>>> profitable to email spammers - it will exist, email spam caused the >>>> illegal anonymous organization "The Spamhaus Project" to exist, >>>> "The Spamhaus Project" is hurting and damaging many businesses >>>> worldwide in their way to fight email spam, "The Spamhaus Project" >>>> is an illegal anonymous organization according to the following >>>> presentation that they wrote on themselves, they are violating laws >>>> in their way to fight email spam and still they don't win in the >>>> battle against email spam. "The Spamhaus Project" is keeping their >>>> anonymity because they are afriad of justified lawsuits due to >>>> their criminal actions in their way to fight email spam. The >>>> following technical solution will resolve the world email spam >>>> problem without to hurt and to damage many businesses worldwide >>>> that have nothing to do with email spam like "The Spamhaus Project" >>>> does, the following implementation can remove the need for an >>>> illegal anonymous organization such as "The Spamhaus Project". >>>> >>>> >>>> The presentation that the illegal anonymous organization "The >>>> Spamhaus Project" wrote on themselves: >>>> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >>>> >>>> >>>> >>>> The Implementation: >>>> >>>> There will be a site (lets call it NoSpam.org) - the site will be >>>> owned by the 5 RIRs, the site will use bgp anycast and will be >>>> deployed in each of the 5 RIRs (the site will also be able to be >>>> deployed by the ccTLD registries in each country), the site in all >>>> the locations will be synced automatically. >>>> >>>> Each domain owner will be able to register at the site (an email >>>> message will be sent to the domain owner email address in the >>>> domain name WHOIS details in order to verify that the domain owner >>>> is the one registering). >>>> >>>> After being logged in, a domain owner will be able to add his email >>>> addresses (of the specific domain name) that will be used to send >>>> newsletters / mailing lists / one-to-many email messages, lets call >>>> these kind of email addresses as 'mailing list' email addresses. >>>> The domain owner will not be able to see the list of 'mailing list' >>>> email addresses that he added - because when he added each 'mailing >>>> list' email address it will be saved with hash in the NoSpam.org >>>> backend infrastructure (due to privacy and security reasons) - >>>> hence only if the domain owner will manually type the 'mailing >>>> list' email address he will be able to enter it in order to manage >>>> it (to see the total number of subscribers email addresses, to see >>>> the subscribers email addresses but only with their hashes due to >>>> security and privacy reasons, to remove a subscriber from the list, >>>> to add a sub-user with permissions to manage that specific 'mailing >>>> list' email address). >>>> >>>> In his site, the domain owner will be able to integrate an iframe >>>> from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a >>>> subscriber registration form to his specific 'mailing list' email >>>> address, the subscriber will receive an email message with a link >>>> to confirm his subscription. >>>> >>>> The domain owner will need to create a callback file in his >>>> website, for example in the path: "/nospam-notification-callback" >>>> (http://example.com/nospam-notification-callback) - that url will >>>> receive encrypted post notifications (encryption key will be >>>> provided by the domain owner in his NoSpam.org logged in account) >>>> from NoSpam.org regarding any new end-user that will subscribe or >>>> that will unsubscribe from a 'mailing address' email address which >>>> is related to the domain of the domain owner (unsubscribe >>>> functionality by the user later below). >>>> >>>> The subscriber email address and that 'mailing list' email address >>>> (that was subscribed to) will be sent by NoSpam.org to >>>> "/nospam-notification-callback" not in the hashed format but in >>>> cleartext (so the domain owner will be able to save it in his >>>> system for future email messages from the specific 'mailing list' >>>> email address to the specific subscriber email address). >>>> >>>> The domain owner will also have an API to NoSpam.org backend >>>> infrastructure in order to remove a specific subscriber email >>>> address from a specific 'mailing list' email address (the domains >>>> owner will send the values through the API - hashed). >>>> >>>> The domain owner will also provide a web interface in his site for >>>> the end-user to remove himself from the specific 'mailing list' >>>> email address. >>>> >>>> >>>> >>>> The above is the backend implementation (no upgrade is needed to >>>> any email server in the internet), the following is the upgrade >>>> that will needed for any email client (that upgrade is not >>>> mandatory, without the following upgrade the email client will work >>>> exactly as it is now without the added no-spam features, electronic >>>> mail will not break if some email users will upgrade their email >>>> clients and some will not): >>>> >>>> - There will not be 'mark as spam' button, that kind of >>>> functionality will stop to exist because spam is not a boolean >>>> value, 'spam' to one person is valuable to another 'person', >>>> specially when the internet is global and different people from >>>> different countries will consider spam content differently. One >>>> user can consider an email message as spam and another user can >>>> consider the same message as not spam, 'Spam' is subjective and any >>>> kind of 'mark as spam' functionality is useless in the battle >>>> against email spam. >>>> >>>> - There will be blacklists and whitelists (just like there are now, >>>> but they will be more prominent): blacklist email addresses , >>>> blacklist domains , whitelist email addresses , whitelist domains. >>>> >>>> - The end-user should be able to easily enter each email message to >>>> whitelist or to blacklist (meaning the 'from' email address of the >>>> email message), and will be able to search in the 'Spam' folder >>>> easily for an email address (these features can exist today, but >>>> they should be given more visibility, so end-users will use them more). >>>> >>>> - The end-user will be able to import/export his whitelists and >>>> blacklists using an xml format to any other upgraded email client, >>>> the blacklists and whitelists will be local (end-user will be able >>>> to pass the local whitelists and blacklists to another email client >>>> of his with the click of a button in the upgraded email client - >>>> the upgraded email client will just send them to itself - without >>>> to download them from the email server so the end-user will be able >>>> to download it with another upgraded email client - or the end-user >>>> will be able to send the whitelists and blacklists to another email >>>> address of him, the usage will not be like sending regular email >>>> message with attachments - the upgraded email clients will take >>>> care to sending and receiving of the blacklists and whitelits - in >>>> the background, these are custom formatted email messages that the >>>> two upgraded email clients will know how to act upon them). >>>> >>>> - The email client will be able to display with GUI with buttons >>>> any 'mailing-list registration confirmation email' in a specific >>>> section related to registration to new 'mailing list' email >>>> addresses for the end-user to choose with buttons if he accept or >>>> refuse to register to a specific 'mailing list' email address. >>>> >>>> - For any email message that was received: in case a received >>>> 'from' email address was found in the whitelist email addresses or >>>> in the whitelist domains - then it will be moved to the 'Inbox' >>>> folder, in case the 'from' email address of the email message was >>>> found in the blacklist email addresses or in the blacklist domains >>>> - then the email message will be moved to the 'Trash' folder. >>>> >>>> - In case the 'from' email address or domain was not found in the >>>> whitelists and in the blacklists, then the upgraded email client >>>> will send the 'from' email address and the 'from' domain and the >>>> current user email address and the external links that exist in the >>>> email message (but all of these data will be sent in a hashed way, >>>> and not in cleartext) with a query to NoSpam.org backend >>>> infrastructure, NoSpam.org will perform the following algorithem >>>> after it: >>>> >>>> - If the hashed 'from' domain (or any other 'hashed' domain from >>>> the external links) exist in a list of criminals hashed domains (of >>>> phishing/malware/viruses/etc) then NoSpam.org will respond to the >>>> email client to delete the email message, otherwise the hashed >>>> 'from' email address will be checked against a list of hashed >>>> 'mailing list' email addresses - if found then the sender is a >>>> 'mailing list' email address and there will be a check by >>>> NoSpam.org backend infrastructure if the hashed 'receiver' email >>>> address is a subscriber of that specific 'mailing list' email >>>> address , if the hashed 'receiver' was found then NoSpam.org will >>>> send a response to the email client that the email message can be >>>> displayed in the 'Inbox' folder and in the response NoSpam.org will >>>> also include an unsubscribe key - the email client will be able to >>>> display an unsubscribe button to the email client and if clicked >>>> the email client will send an https request to NoSpam.org with the >>>> specific unsubscribe key, NoSpam.org backend infrastructure will >>>> remove the end-user email address from the 'mailing list' email >>>> address and will notify the domain owner at the domain owner >>>> callback url "/nospam-notification-callback" that the specific user >>>> unsubscribed. In case the hashed 'receiver' wasn't found then >>>> NoSpam.org will respond to the email client to delete the email >>>> message and NoSpam.org will also notify the callback url of the >>>> related domain owner that he shouldn't send email messages from the >>>> specific 'mailing ?list' email address to the specific subscriber >>>> email address. >>>> >>>> - In case when NoSpam.org backend infrastructure searched the >>>> hashed 'from' email address and it wasn't found in the list of all >>>> hashed 'mailing list' email addresses, it mean that the email >>>> address was sent from a 'personal' email address and NoSpam.org >>>> backend infrastructure will notify the email client that the email >>>> message is from a 'personal' email address - the email client in >>>> that stage will need to decide if to move the email message to the >>>> 'Inbox' folder or to the 'Spam' folder based on the following - the >>>> email client will check if the email message include >>>> links/images/plain-url's - and if yes then the email message will >>>> be moved to the 'Spam' folder, otherwise it will be moved to the >>>> 'Inbox' folder. >>>> >>>> >>>> >>>> >>>> Whitelist Handshake: >>>> >>>> - In order to facilitate the adding of new email address to the >>>> local whitelist, a process of 'Whitelist Handshake' exist , a >>>> 'Whitelist Handshake' is a GUI representation in two email clients >>>> regarding background email messages between them (that the two >>>> end-users don't see), "end-user A" with a click of a button will be >>>> able to send 'add me to whitelist' request to "end-user B" which >>>> will be able to accept or deny and if accepted then "end-user B" >>>> will be able to automatically send the same "add me to whitelist" >>>> request to "end-user A" , all of this communication will be done >>>> behind the scenes, these special email messages will not be visible >>>> to the end-users, end-users will see popups with GUI that email >>>> address X is asking to be added to whitelist. In order for spammers >>>> not to abuse this option - the email client will keep only one >>>> 'whitelist request' from each requester email address (there will >>>> be a 'whitelist requests' section in the upgraded email client). A >>>> repeated 'whitelist request' that came from a specific email >>>> address can never be raised in the list (unless the end-user will >>>> specifically search for it) even when the sender will send more and >>>> more 'add me to whitelist' requests - no priority will given to >>>> them, and once an end-user refused an 'add me to whitelist' request >>>> - no new 'add me to whitelist' request will be shown from the >>>> specific sender email address in the specific email client. >>>> >>>> - There can be a case that an upgraded email client will send 'add >>>> me to whitelist' request to a not-upgraded email client and then >>>> the receiver will see the request as it is - as an email message in >>>> the inbox folder - due to it the content of that message will be in >>>> the language of the domain TLD of the receiver email address and >>>> the content in the email message will explain what is NoSpam.org >>>> and how to upgrade the email client and supported upgraded email >>>> clients, etc >>>> >>>> - In the 'whitelist requests section' in the upgraded email client >>>> - the whitelist requests will appear in a list - there should be >>>> preference so some requests will appear upper and other lower (so >>>> requests from spammers will appear lower) - whitelist requests from >>>> email addresses of domains which are older (according to their >>>> WHOIS details) will appear upper than whitelist requests from email >>>> addresses of domains which are newer. Whitelist requests from a >>>> list of a more-trusted-domains (domains of known webmails service, >>>> universities, governments, etc) will have preference over other >>>> domains, specific TLDs that not anyone can purchase will also have >>>> preference over other TLDs that anyone can purchase (upgraded email >>>> clients will retrieve the list of trusted TLD's and Domains each >>>> day from NoSpam.org backend infrastructure). >>>> >>>> >>>> Notification of spam emails: >>>> >>>> - An additional feature in the upgraded email client is that >>>> whenever an email message will reach the 'Spam' folder - the email >>>> client will send in the background a known-format email message to >>>> the sender and will notify him about it, if the sender is using an >>>> upgraded email client then it will be able to automatically send a >>>> 'add me to whitelist' request to the receiver in the background >>>> (once an email address is whitelisted - all the email messages from >>>> it will move from 'Spam' to 'Inbox'). >>>> >>>> >>>> >>>> Email Spoofing: >>>> >>>> - In an upgraded email client, email messages from 'personal' email >>>> addresses cannot arrive from email relay server, in case it happen >>>> the message will be deleted and the email client will send an >>>> automatic email message in the background to the sender with the >>>> text (in the language of the sender domain TLD) that email messages >>>> from 'email relay servers' cannot be received from him. >>>> >>>> - In an upgraded email client, email messages from 'mailing list' >>>> email addresses can arrive from email relay servers - but they must >>>> be encrypted with DKIM. >>>> >>>> - In an upgraded email client, the email client should check the >>>> SPF txt dns record of the sender domain, and will drop the email >>>> message if it is a spoofed email message. >>>> >>>> - DNS servers developers will need to make the SPF txt dns record >>>> to be a mandatory field for every domain, in order for email >>>> spoofing to be annihilated. >>>> >>>> >>>> >>>> Security Aspects: >>>> >>>> - All stored data in NoSpam.org Backend infrastructure is hashed. >>>> >>>> - The criminals domains list in NoSpam.org Backend Infrastructure >>>> will be managed only by regulated supervised Law Enforcement Agency >>>> (for example: Interpol) and not by an internet organization such as >>>> the RIRs or ccTLD registries. >>>> >>>> - Domains owners will have 'forgot password' functionality to their >>>> NoSpam.org account, the password reset link will be sent to the >>>> email address of the owner of the domain according to the domain >>>> WHOIS details. >>>> >>>> - Communication between email clients to NoSpam.org backend >>>> infrastructure will be over https, there will only be an handshake >>>> process in the beginning over electronic mail between email client >>>> and NoSpam.org backend infrastructure - the email client will send >>>> an email message with a chosen key to an email address of >>>> @nospam.org (that key will be used in further communication between >>>> the email client and the NoSpam.org backend infrastructure over >>>> https, it will be used for NoSpam.org backend infrastructure to >>>> identify the specific email address over https, so anyone will not >>>> be able to query NoSpam.org backend infrastructure to know which >>>> hashed email address belongs to which hashed 'mailing list' email >>>> address, besides the email client user with the right key to query >>>> NoSpam.org Backend infrastructure only on himself). >>>> >>>> - Any email client will download once per day 'spam-rules' file >>>> from NoSpam.org backend infrastructure, 'spam-rules' file will be >>>> an xml formatted file that include rules of when to move an email >>>> message that was received from 'personal' email address which is >>>> not whitelisted to the 'Spam' folder (for example, when email have >>>> at least 1/2/3 links, when email format is rich text or html and >>>> not plaintext, etc), in case future adjustments will be needed to >>>> win the battle against email spam - email clients will not need to >>>> be upgraded, the new 'spam-rules' will be updated in this daily file. >>>> >>>> >>>> To make it short: >>>> >>>> - Any email message from a subscribed mailing list / newsletter / >>>> etc - will reach to the inbox (that kind of email messages can >>>> contain any kind of content without any restrictions, because the >>>> user subscribed to it and the user can unsubscribe from it at anytime). >>>> >>>> - Any email message from an email address or domain in whitelist - >>>> will reach the inbox. >>>> >>>> - Whitelist Handshake process is easy to use and being implemented >>>> with clicks of a button, nothing to type. >>>> >>>> - In case an email message will the 'Spam' folder - an automatic >>>> email message will be sent from the receiver to sender and sender >>>> can automatically ask to be added to the receiver's whitelist. >>>> >>>> - Any email message without links/images/plain-url's (plain email >>>> messages, like electronic email was) - will reach the inbox. >>>> >>>> - Any other email will reach the 'Spam' folder - if needed the user >>>> will be able to easily whitelist the email message in the 'Spam' >>>> folder. >>>> >>>> >>>> >>>> Spammers need links in their email messages for monetization, above >>>> solution blocks it and also block criminal domains links in email >>>> message and implement email spoofing blocking at client-side. We >>>> will all stop to receive more than 100 spam email messages per day >>>> with the above solution. >>>> >>>> >>>> Respectfully, >>>> Elad >>>> >>>> _______________________________________________ >>>> members-discuss mailing list >>>> members-discuss at ripe.net >>>> https://lists.ripe.net/mailman/listinfo/members-discuss >>>> Unsubscribe: >>>> https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net >>>> >>> >> > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/silvan%40unavailable.online -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengan at resilans.se Sun Apr 26 21:33:42 2020 From: bengan at resilans.se (=?UTF-8?B?QmVuZ3QgR8O2cmTDqW4=?=) Date: Sun, 26 Apr 2020 21:33:42 +0200 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> Message-ID: <7c420f08-a5cd-9c22-cf33-662726f21467@resilans.se> On 2020-04-26 19:20, Elad Cohen wrote: > This is not up to you to decide. > > This is a membership discuss mailing list, I'm a member just like you are, > please don't shut conversations and tell what we can or cannot talk about, > Spam is a problem that is related to all Ripe LIR members including you. https://www.ripe.net/ripe/mail/archives/members-discuss/2007-March/000000.html -- bengan -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 22:56:25 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 20:56:25 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <2fad3198-4fcc-4783-98ed-cbb2cc0a30de@www.fastmail.com> <7a5af760-42ca-b807-6f40-b791fa4b6c39@fastmail.net> , Message-ID: The spamhaus fans just cannot sit quietly in their corner. "I know you will find again great words to reply" If you wish. I'm willing to have a discussion with anyone, but a constructive discussion, not a discussion with people which have hidden interests, with people that were sent by candidates (and candidates themselves that are showing up here and yelling), not with people that their actions is due to fear. I'm not fighting everyone, on the contrary - If I will have the honor of being elected, you can be sure that I will fight for the interests of each and every one of you. I only asked the illegal anonymous organization spamhaus fans to be quiet if they want me to post my last technical solution and they know exactly who they are, I respect everyone else and I respect Ripe. Regarding the "leadership qualities" that you are referring to, I definitely not have the "leadership qualities" of our Chairman as was written about him here: https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html But there is only one problem with it, when our board member Maria pasted to the textarea the text that our Chairman wrote on himself and sent to her - she forgot to remove the title from it, so this is what we see in the above link: "Reason for nominating the candidate: Reason for nominating the candidate: " the second same title is because a copy-paste was done here, our Chairman, 15 minutes after he nominated Maria with a single sentence - sent a whole paragraph on himself to Maria for her to use it when she nominated him, this is what our Chairman wrote on himself: (among other things in the whole paragraph in the link above) "Christian has shown very strong and positive leadership in his role as chair of the board" If that is what our Chairman and our Board member are doing behind the scenes (Maria cheated the community that these are her words while she didn't even read it, she did only copy-paste), we cannot trust them with managing Ripe expenses and the fact is that thy are denying to reveal detailed financial information and they are denying detailed transparency. so I lack that kind of "leadership qualities" , I do have other leadership qualities - I stood up against "The Spamhaus Project - something that only few dare to do, I'm taking the heat from you each and every day but still it doesn't impact me a bit, yesterday here I stood up against a group of IPv6 deployers that have an interest that IPv4+ will not be implemented - but we all truly know (just like the very vast majority of the internet community) that it is the right thing to do, I stood up against them all, alone. Regarding your last paragraph: "All I can see is a guy, who tries to get elected because he really desperately needs something in his CV, and because the chances might be thin (you haven't even bothered to bring any CV or something up, while at least 3 candidates actually put in the effort so we can judge what they have done in the past. You share nothing of your past, what you have done, where you have participated. instead you try to push your campaign by pushing your own ideas on an unsuitable platform." I will not answer that paragraph because of the way that it is written, you just displayed yourself in it at the darkest distorted light. Where did you see that I'm trying to be elected ? did you see me jumping into other discussion lists and start yelling on candidates ? (like was done here) - do you want me to write about myself like our Chairman did ? I believe in taking the right actions, not in creating the right connections. This is not a campaign - this is me showing my ideas to the community before they will be implemented. I don't believe in living in the past and I personally dislike any kind of bragging. Don't you care about what a candidate will do if and after it will be chosen ? this I didn't hear from anyone. People only know how to talk about themselves. No worries, you will know exactly what are my plans for Ripe and you can be sure that if I will be elected I will take Ripe to its golden age - and each and every LIR member will enjoy from it, until the last one. Silvan, you are obviously supporting another candidate, you shouldn't fear from me, I come with open hands and with a clean heart. Respectfully, Elad ________________________________ From: members-discuss on behalf of Silvan Gebhardt Sent: Sunday, April 26, 2020 10:31 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hi Elad, it's me again, one of your favourite illegals. You are a candidate for the Board of RIPE. as a RIPE board member you should be able to actually have a discussion with people, to engage in disputes in a constructive way, instead you instantly pick a fight, and try to fight everyone who does not agree with your points. You ask that Members here - which are most likely other members of LIRS which have as much a right to state their opinion, "stay quiet" - or you suggest to remove them from the mailinglist. This clearly does not look good for you, Elad - leave the accusations away, you are definitely not displaying any leadership qualities which would be required as board of RIPE. So, accusations against you, you ask for proof. You yourself state accusations against RIPE Board ("corruption") but you do not provide any proof. All I can see is a guy, who tries to get elected because he really desperately needs something in his CV, and because the chances might be thin (you haven't even bothered to bring any CV or something up, while at least 3 candidates actually put in the effort so we can judge what they have done in the past. You share nothing of your past, what you have done, where you have participated. instead you try to push your campaign by pushing your own ideas on an unsuitable platform. I agree that "even bad publicity can be some publicity" - but it will not help you on your election because at this rate, the only vote you get is your own word. I know you will find again great words to reply, it will greatly amuse me. trust me, if you start picking fights with everyone, people will start digging and open up a case with the arbiter under clause 1.2.1.1 section 2 On 4/26/20 7:15 PM, Elad Cohen wrote: If the Spamhaus fans will be quiet in their corner then tomorrow will be the last technical solution. Respectfully, Elad ________________________________ From: Darren Brown Sent: Sunday, April 26, 2020 10:13 PM To: Elad Cohen ; href ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad it?s great you have so many ideas but this is getting a bit silly now, go and take a break , have a drink and put in a film. It?s Sunday evening , chill out Regards Darren Get Outlook for iOS ________________________________ From: members-discuss on behalf of Elad Cohen Sent: Sunday, April 26, 2020 8:09:09 PM To: href ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem "I had no idea that you may have been involved in the Cape Town hijack!" The cyber influence operation continue... complete lies without a single proof, can anyone show a single proof ? Are you so scared from me being elected ? that you need to spread lies ? I'm highly honored that the illegal anonymous organization "The Spamhaus Project" decided to attack me, it means a lot. Lets see who is the Spamhaus fan that will jump now. Respectfully, Elad ________________________________ From: href Sent: Sunday, April 26, 2020 10:01 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad, Some members sent some additional information about you: I can now understand your replies: I had no idea that you may have been involved in the Cape Town hijack! Please forget about my badly chosen example. Accusations aside, it is time to get serious and I'll re-iterate my original question: what are your thoughts and technical solutions about IP hijacking (not the Cape town one) ? On 4/26/20 8:23 PM, Elad Cohen wrote: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. ---- Can you show a single proof to what you are writing? You are taking part in an illegal cyber influence operation against me. Respectfully, Elad ________________________________ From: Jordan Bracco Sent: Sunday, April 26, 2020 9:14 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad, I do not see what you mean by "telling a lie again and again". I have a vague memory of something fishy going on with a Cape Town ip block, but there was many occurences like this. I cited Cape Town as an example. I do not have proof, so maybe the Cape Town is a false memory, but IP hijacking (which was the subject of my email, not Cape Town) surely do happen. For the rest of your reply-- I just simply do not understand it. - I fail to see a correlation between hijacking IP space and Spamhaus. Could you please enlighten me ? - I also fail to understand what you mean by "mob friends just like you". I have no relationship whatsoever with SpamHaus, I do not use their DNSBLs (as I delegate most of my emails to Fastmail). I was just asking for your thoughts and technical solutions to IP space hijacking. Your reply turned into a rant about Spamhaus (?) and accusing me of being "mob friend" of it (?) ? On Sun, Apr 26, 2020, at 19:46, Elad Cohen wrote: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. Respectfully, Elad ________________________________ From: members-discuss on behalf of Jordan Bracco Sent: Sunday, April 26, 2020 8:23 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Dear Elad, Unrelated to the spam proposal-- but have you found a technical solution to avoid malicious third parties to hijack assigned IP space (for example, if I remember that there was some IP space from Cape Town city that got hijacked). What are you thoughts on this, and your technical solution to it ? On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/silvan%40unavailable.online -------------- next part -------------- An HTML attachment was scrubbed... URL: From campbell at inca.ie Sun Apr 26 23:25:56 2020 From: campbell at inca.ie (Ed Campbell) Date: Sun, 26 Apr 2020 22:25:56 +0100 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: Message-ID: <1E0D3039-E78B-49C8-BC41-5E1322373A36@inca.ie> Where is the proof that Spamhaus, an UK organization, are illegal or are ran by a mob? Hopefully you don?t mean that Illinois court ruling? Without a court ruling on this that is also defamation. Perhaps we can stick to what this list is for, rather than making silly accusations. Sent from my iPhone > On 26 Apr 2020, at 21:58, Elad Cohen wrote: > > ? > The spamhaus fans just cannot sit quietly in their corner. > > "I know you will find again great words to reply" > > If you wish. > > I'm willing to have a discussion with anyone, but a constructive discussion, not a discussion with people which have hidden interests, with people that were sent by candidates (and candidates themselves that are showing up here and yelling), not with people that their actions is due to fear. > > I'm not fighting everyone, on the contrary - If I will have the honor of being elected, you can be sure that I will fight for the interests of each and every one of you. > > I only asked the illegal anonymous organization spamhaus fans to be quiet if they want me to post my last technical solution and they know exactly who they are, I respect everyone else and I respect Ripe. > > > Regarding the "leadership qualities" that you are referring to, I definitely not have the "leadership qualities" of our Chairman as was written about him here: > https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html > > But there is only one problem with it, when our board member Maria pasted to the textarea the text that our Chairman wrote on himself and sent to her - she forgot to remove the title from it, so this is what we see in the above link: > > "Reason for nominating the candidate: > Reason for nominating the candidate: " > > the second same title is because a copy-paste was done here, our Chairman, 15 minutes after he nominated Maria with a single sentence - sent a whole paragraph on himself to Maria for her to use it when she nominated him, this is what our Chairman wrote on himself: (among other things in the whole paragraph in the link above) > "Christian has shown very strong and positive leadership in his role as chair of the board" > > If that is what our Chairman and our Board member are doing behind the scenes (Maria cheated the community that these are her words while she didn't even read it, she did only copy-paste), we cannot trust them with managing Ripe expenses and the fact is that thy are denying to reveal detailed financial information and they are denying detailed transparency. > > so I lack that kind of "leadership qualities" , I do have other leadership qualities - I stood up against "The Spamhaus Project - something that only few dare to do, I'm taking the heat from you each and every day but still it doesn't impact me a bit, yesterday here I stood up against a group of IPv6 deployers that have an interest that IPv4+ will not be implemented - but we all truly know (just like the very vast majority of the internet community) that it is the right thing to do, I stood up against them all, alone. > > > Regarding your last paragraph: > > "All I can see is a guy, who tries to get elected because he really desperately needs something in his CV, and because the chances might be thin (you haven't even bothered to bring any CV or something up, while at least 3 candidates actually put in the effort so we can judge what they have done in the past. You share nothing of your past, what you have done, where you have participated. instead you try to push your campaign by pushing your own ideas on an unsuitable platform." > > I will not answer that paragraph because of the way that it is written, you just displayed yourself in it at the darkest distorted light. Where did you see that I'm trying to be elected ? did you see me jumping into other discussion lists and start yelling on candidates ? (like was done here) - do you want me to write about myself like our Chairman did ? I believe in taking the right actions, not in creating the right connections. This is not a campaign - this is me showing my ideas to the community before they will be implemented. I don't believe in living in the past and I personally dislike any kind of bragging. Don't you care about what a candidate will do if and after it will be chosen ? this I didn't hear from anyone. People only know how to talk about themselves. No worries, you will know exactly what are my plans for Ripe and you can be sure that if I will be elected I will take Ripe to its golden age - and each and every LIR member will enjoy from it, until the last one. > > Silvan, you are obviously supporting another candidate, you shouldn't fear from me, I come with open hands and with a clean heart. > > Respectfully, > Elad > From: members-discuss on behalf of Silvan Gebhardt > Sent: Sunday, April 26, 2020 10:31 PM > To: members-discuss at ripe.net > Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem > > Hi Elad, it's me again, one of your favourite illegals. > > > > > > > > You are a candidate for the Board of RIPE. > > as a RIPE board member you should be able to actually have a discussion with people, to engage in disputes in a constructive way, instead you instantly pick a fight, and try to fight everyone who does not agree with your points. > > You ask that Members here - which are most likely other members of LIRS which have as much a right to state their opinion, "stay quiet" - or you suggest to remove them from the mailinglist. > > > This clearly does not look good for you, Elad - leave the accusations away, you are definitely not displaying any leadership qualities which would be required as board of RIPE. > > > So, accusations against you, you ask for proof. > > You yourself state accusations against RIPE Board ("corruption") but you do not provide any proof. > > All I can see is a guy, who tries to get elected because he really desperately needs something in his CV, and because the chances might be thin (you haven't even bothered to bring any CV or something up, while at least 3 candidates actually put in the effort so we can judge what they have done in the past. You share nothing of your past, what you have done, where you have participated. instead you try to push your campaign by pushing your own ideas on an unsuitable platform. > > I agree that "even bad publicity can be some publicity" - but it will not help you on your election because at this rate, the only vote you get is your own word. > > > > > > I know you will find again great words to reply, it will greatly amuse me. > > > > > > trust me, if you start picking fights with everyone, people will start digging and open up a case with the arbiter under clause 1.2.1.1 section 2 > > > >> On 4/26/20 7:15 PM, Elad Cohen wrote: >> If the Spamhaus fans will be quiet in their corner then tomorrow will be the last technical solution. >> >> Respectfully, >> Elad >> From: Darren Brown >> Sent: Sunday, April 26, 2020 10:13 PM >> To: Elad Cohen ; href ; members-discuss at ripe.net >> Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem >> >> Elad it?s great you have so many ideas but this is getting a bit silly now, go and take a break , have a drink and put in a film. It?s Sunday evening , chill out >> >> Regards >> Darren >> >> Get Outlook for iOS >> From: members-discuss on behalf of Elad Cohen >> Sent: Sunday, April 26, 2020 8:09:09 PM >> To: href ; members-discuss at ripe.net >> Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem >> >> "I had no idea that you may have been involved in the Cape Town hijack!" >> >> The cyber influence operation continue... complete lies without a single proof, can anyone show a single proof ? >> >> Are you so scared from me being elected ? that you need to spread lies ? >> >> I'm highly honored that the illegal anonymous organization "The Spamhaus Project" decided to attack me, it means a lot. >> >> Lets see who is the Spamhaus fan that will jump now. >> >> Respectfully, >> Elad >> From: href >> Sent: Sunday, April 26, 2020 10:01 PM >> To: Elad Cohen ; members-discuss at ripe.net >> Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem >> >> Elad, >> >> >> >> Some members sent some additional information about you: I can now understand your replies: I had no idea that you may have been involved in the Cape Town hijack! >> >> >> >> Please forget about my badly chosen example. Accusations aside, it is time to get serious and I'll re-iterate my original question: what are your thoughts and technical solutions about IP hijacking (not the Cape town one) ? >> >> >> >> >> >>> On 4/26/20 8:23 PM, Elad Cohen wrote: >>> Jordan, >>> >>> What you are writing is false, telling a lie again and again will not make it truth. >>> >>> "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) >>> >>> And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: >>> >>> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >>> >>> "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. >>> >>> ---- >>> >>> Can you show a single proof to what you are writing? You are taking part in an illegal cyber influence operation against me. >>> >>> Respectfully, >>> Elad >>> >>> From: Jordan Bracco >>> Sent: Sunday, April 26, 2020 9:14 PM >>> To: Elad Cohen ; members-discuss at ripe.net >>> Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem >>> >>> Elad, >>> >>> I do not see what you mean by "telling a lie again and again". I have a vague memory of something fishy going on with a Cape Town ip block, but there was many occurences like this. I cited Cape Town as an example. I do not have proof, so maybe the Cape Town is a false memory, but IP hijacking (which was the subject of my email, not Cape Town) surely do happen. >>> >>> For the rest of your reply-- I just simply do not understand it. >>> >>> - I fail to see a correlation between hijacking IP space and Spamhaus. Could you please enlighten me ? >>> - I also fail to understand what you mean by "mob friends just like you". I have no relationship whatsoever with SpamHaus, I do not use their DNSBLs (as I delegate most of my emails to Fastmail). >>> >>> I was just asking for your thoughts and technical solutions to IP space hijacking. Your reply turned into a rant about Spamhaus (?) and accusing me of being "mob friend" of it (?) ? >>> >>> On Sun, Apr 26, 2020, at 19:46, Elad Cohen wrote: >>>> Jordan, >>>> >>>> What you are writing is false, telling a lie again and again will not make it truth. >>>> >>>> "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) >>>> >>>> And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: >>>> >>>> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >>>> >>>> "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. >>>> >>>> Respectfully, >>>> Elad >>>> >>>> >>>> >>>> From: members-discuss on behalf of Jordan Bracco >>>> Sent: Sunday, April 26, 2020 8:23 PM >>>> To: members-discuss at ripe.net >>>> Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem >>>> >>>> Dear Elad, >>>> >>>> Unrelated to the spam proposal-- but have you found a technical solution to avoid malicious third parties to hijack assigned IP space (for example, if I remember that there was some IP space from Cape Town city that got hijacked). What are you thoughts on this, and your technical solution to it ? >>>> >>>> >>>>> On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: >>>>> Hello Everyone, >>>>> >>>>> I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). >>>>> >>>>> Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". >>>>> >>>>> >>>>> The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: >>>>> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >>>>> >>>>> >>>>> >>>>> The Implementation: >>>>> >>>>> There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. >>>>> >>>>> Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). >>>>> >>>>> After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). >>>>> >>>>> In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. >>>>> >>>>> The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). >>>>> >>>>> The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). >>>>> >>>>> The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). >>>>> >>>>> The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. >>>>> >>>>> >>>>> >>>>> The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): >>>>> >>>>> - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. >>>>> >>>>> - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. >>>>> >>>>> - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). >>>>> >>>>> - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). >>>>> >>>>> - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. >>>>> >>>>> - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. >>>>> >>>>> - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: >>>>> >>>>> - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. >>>>> >>>>> - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. >>>>> >>>>> >>>>> >>>>> >>>>> Whitelist Handshake: >>>>> >>>>> - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. >>>>> >>>>> - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc >>>>> >>>>> - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). >>>>> >>>>> >>>>> Notification of spam emails: >>>>> >>>>> - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). >>>>> >>>>> >>>>> >>>>> Email Spoofing: >>>>> >>>>> - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. >>>>> >>>>> - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. >>>>> >>>>> - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. >>>>> >>>>> - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. >>>>> >>>>> >>>>> >>>>> Security Aspects: >>>>> >>>>> - All stored data in NoSpam.org Backend infrastructure is hashed. >>>>> >>>>> - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. >>>>> >>>>> - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. >>>>> >>>>> - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). >>>>> >>>>> - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. >>>>> >>>>> >>>>> To make it short: >>>>> >>>>> - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). >>>>> >>>>> - Any email message from an email address or domain in whitelist - will reach the inbox. >>>>> >>>>> - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. >>>>> >>>>> - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. >>>>> >>>>> - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. >>>>> >>>>> - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. >>>>> >>>>> >>>>> >>>>> Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. >>>>> >>>>> >>>>> Respectfully, >>>>> Elad >>>>> >>>>> _______________________________________________ >>>>> members-discuss mailing list >>>>> members-discuss at ripe.net >>>>> https://lists.ripe.net/mailman/listinfo/members-discuss >>>>> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net >>>>> >>>> >>> >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/silvan%40unavailable.online > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From dk at hostmaster.ua Sun Apr 26 23:31:42 2020 From: dk at hostmaster.ua (Dmitry Kohmanyuk) Date: Mon, 27 Apr 2020 00:31:42 +0300 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> Message-ID: <17952E6B-D360-4A4D-95C7-06137D898885@hostmaster.ua> On Apr 26, 2020, at 20:04, Simon Lockhart wrote: >> On 26 Apr 2020, at 17:50, Matthias Brumm wrote: >> Do you have an ellaborated guess, how much computing power that would need? > > The billions of dollars/euros that will be generated from the creation of IPv4+ will fund the massive server infrastructure. And all the profit from Great New Spam filter would be dedicated to get rid of COVID-19. Right, Elad?.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 23:36:51 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 21:36:51 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <1E0D3039-E78B-49C8-BC41-5E1322373A36@inca.ie> References: , <1E0D3039-E78B-49C8-BC41-5E1322373A36@inca.ie> Message-ID: According to the following link, which is a presentation that Spamhaus wrote on themselves and showed in a private event, Spamhaus is receiving high amount of illegaly-obtained privacy data of internet users from their contacts inside internet organizations and internet companies, and then (according to their presentation) they share it in illegal way without any warrant with law enforcement agencies, this is completely illegal because it is done in a systematic regular way, this is the reason that they are keeping their anonymity, this is the reason that Law Enforcement Agencies are doing nothing regarding Spamhaus (because Spamhaus is providing them on a regular basis and in a systematic methods - massive amount of illegaly-obtained intelligence data) despite all the many complaints worldwide against Spamhaus. https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The author of that private presentation as written in it is Richard D G Cox who was the co-chair of the ripe anti-abuse working group, there are more secret contacts of Spamhaus inside Ripe just like Richard D G Cox was, they are usually the ones that are trying to manipulate public opinion without any single proof, just like was done against me today. These people (Spamhaus secret contacts just like Richard D G Cox was) are bringing politics inside internet organizations, create cyber influence operations, targeting the people that they cannot control and so on. Spamhaus is an highly illegal anonymous organization and the above presentation link shows it in their own words. Respectfully, Elad ________________________________ From: Ed Campbell Sent: Monday, April 27, 2020 12:25 AM To: Elad Cohen Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Where is the proof that Spamhaus, an UK organization, are illegal or are ran by a mob? Hopefully you don?t mean that Illinois court ruling? Without a court ruling on this that is also defamation. Perhaps we can stick to what this list is for, rather than making silly accusations. Sent from my iPhone On 26 Apr 2020, at 21:58, Elad Cohen wrote: ? The spamhaus fans just cannot sit quietly in their corner. "I know you will find again great words to reply" If you wish. I'm willing to have a discussion with anyone, but a constructive discussion, not a discussion with people which have hidden interests, with people that were sent by candidates (and candidates themselves that are showing up here and yelling), not with people that their actions is due to fear. I'm not fighting everyone, on the contrary - If I will have the honor of being elected, you can be sure that I will fight for the interests of each and every one of you. I only asked the illegal anonymous organization spamhaus fans to be quiet if they want me to post my last technical solution and they know exactly who they are, I respect everyone else and I respect Ripe. Regarding the "leadership qualities" that you are referring to, I definitely not have the "leadership qualities" of our Chairman as was written about him here: https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html But there is only one problem with it, when our board member Maria pasted to the textarea the text that our Chairman wrote on himself and sent to her - she forgot to remove the title from it, so this is what we see in the above link: "Reason for nominating the candidate: Reason for nominating the candidate: " the second same title is because a copy-paste was done here, our Chairman, 15 minutes after he nominated Maria with a single sentence - sent a whole paragraph on himself to Maria for her to use it when she nominated him, this is what our Chairman wrote on himself: (among other things in the whole paragraph in the link above) "Christian has shown very strong and positive leadership in his role as chair of the board" If that is what our Chairman and our Board member are doing behind the scenes (Maria cheated the community that these are her words while she didn't even read it, she did only copy-paste), we cannot trust them with managing Ripe expenses and the fact is that thy are denying to reveal detailed financial information and they are denying detailed transparency. so I lack that kind of "leadership qualities" , I do have other leadership qualities - I stood up against "The Spamhaus Project - something that only few dare to do, I'm taking the heat from you each and every day but still it doesn't impact me a bit, yesterday here I stood up against a group of IPv6 deployers that have an interest that IPv4+ will not be implemented - but we all truly know (just like the very vast majority of the internet community) that it is the right thing to do, I stood up against them all, alone. Regarding your last paragraph: "All I can see is a guy, who tries to get elected because he really desperately needs something in his CV, and because the chances might be thin (you haven't even bothered to bring any CV or something up, while at least 3 candidates actually put in the effort so we can judge what they have done in the past. You share nothing of your past, what you have done, where you have participated. instead you try to push your campaign by pushing your own ideas on an unsuitable platform." I will not answer that paragraph because of the way that it is written, you just displayed yourself in it at the darkest distorted light. Where did you see that I'm trying to be elected ? did you see me jumping into other discussion lists and start yelling on candidates ? (like was done here) - do you want me to write about myself like our Chairman did ? I believe in taking the right actions, not in creating the right connections. This is not a campaign - this is me showing my ideas to the community before they will be implemented. I don't believe in living in the past and I personally dislike any kind of bragging. Don't you care about what a candidate will do if and after it will be chosen ? this I didn't hear from anyone. People only know how to talk about themselves. No worries, you will know exactly what are my plans for Ripe and you can be sure that if I will be elected I will take Ripe to its golden age - and each and every LIR member will enjoy from it, until the last one. Silvan, you are obviously supporting another candidate, you shouldn't fear from me, I come with open hands and with a clean heart. Respectfully, Elad ________________________________ From: members-discuss on behalf of Silvan Gebhardt Sent: Sunday, April 26, 2020 10:31 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hi Elad, it's me again, one of your favourite illegals. You are a candidate for the Board of RIPE. as a RIPE board member you should be able to actually have a discussion with people, to engage in disputes in a constructive way, instead you instantly pick a fight, and try to fight everyone who does not agree with your points. You ask that Members here - which are most likely other members of LIRS which have as much a right to state their opinion, "stay quiet" - or you suggest to remove them from the mailinglist. This clearly does not look good for you, Elad - leave the accusations away, you are definitely not displaying any leadership qualities which would be required as board of RIPE. So, accusations against you, you ask for proof. You yourself state accusations against RIPE Board ("corruption") but you do not provide any proof. All I can see is a guy, who tries to get elected because he really desperately needs something in his CV, and because the chances might be thin (you haven't even bothered to bring any CV or something up, while at least 3 candidates actually put in the effort so we can judge what they have done in the past. You share nothing of your past, what you have done, where you have participated. instead you try to push your campaign by pushing your own ideas on an unsuitable platform. I agree that "even bad publicity can be some publicity" - but it will not help you on your election because at this rate, the only vote you get is your own word. I know you will find again great words to reply, it will greatly amuse me. trust me, if you start picking fights with everyone, people will start digging and open up a case with the arbiter under clause 1.2.1.1 section 2 On 4/26/20 7:15 PM, Elad Cohen wrote: If the Spamhaus fans will be quiet in their corner then tomorrow will be the last technical solution. Respectfully, Elad ________________________________ From: Darren Brown Sent: Sunday, April 26, 2020 10:13 PM To: Elad Cohen ; href ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad it?s great you have so many ideas but this is getting a bit silly now, go and take a break , have a drink and put in a film. It?s Sunday evening , chill out Regards Darren Get Outlook for iOS ________________________________ From: members-discuss on behalf of Elad Cohen Sent: Sunday, April 26, 2020 8:09:09 PM To: href ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem "I had no idea that you may have been involved in the Cape Town hijack!" The cyber influence operation continue... complete lies without a single proof, can anyone show a single proof ? Are you so scared from me being elected ? that you need to spread lies ? I'm highly honored that the illegal anonymous organization "The Spamhaus Project" decided to attack me, it means a lot. Lets see who is the Spamhaus fan that will jump now. Respectfully, Elad ________________________________ From: href Sent: Sunday, April 26, 2020 10:01 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad, Some members sent some additional information about you: I can now understand your replies: I had no idea that you may have been involved in the Cape Town hijack! Please forget about my badly chosen example. Accusations aside, it is time to get serious and I'll re-iterate my original question: what are your thoughts and technical solutions about IP hijacking (not the Cape town one) ? On 4/26/20 8:23 PM, Elad Cohen wrote: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. ---- Can you show a single proof to what you are writing? You are taking part in an illegal cyber influence operation against me. Respectfully, Elad ________________________________ From: Jordan Bracco Sent: Sunday, April 26, 2020 9:14 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad, I do not see what you mean by "telling a lie again and again". I have a vague memory of something fishy going on with a Cape Town ip block, but there was many occurences like this. I cited Cape Town as an example. I do not have proof, so maybe the Cape Town is a false memory, but IP hijacking (which was the subject of my email, not Cape Town) surely do happen. For the rest of your reply-- I just simply do not understand it. - I fail to see a correlation between hijacking IP space and Spamhaus. Could you please enlighten me ? - I also fail to understand what you mean by "mob friends just like you". I have no relationship whatsoever with SpamHaus, I do not use their DNSBLs (as I delegate most of my emails to Fastmail). I was just asking for your thoughts and technical solutions to IP space hijacking. Your reply turned into a rant about Spamhaus (?) and accusing me of being "mob friend" of it (?) ? On Sun, Apr 26, 2020, at 19:46, Elad Cohen wrote: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. Respectfully, Elad ________________________________ From: members-discuss on behalf of Jordan Bracco Sent: Sunday, April 26, 2020 8:23 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Dear Elad, Unrelated to the spam proposal-- but have you found a technical solution to avoid malicious third parties to hijack assigned IP space (for example, if I remember that there was some IP space from Cape Town city that got hijacked). What are you thoughts on this, and your technical solution to it ? On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/silvan%40unavailable.online _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Sun Apr 26 23:39:02 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 21:39:02 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: <17952E6B-D360-4A4D-95C7-06137D898885@hostmaster.ua> References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> , <17952E6B-D360-4A4D-95C7-06137D898885@hostmaster.ua> Message-ID: No, Ripe will buy an island with it. Respectfully, Elad ________________________________ From: members-discuss on behalf of Dmitry Kohmanyuk Sent: Monday, April 27, 2020 12:31 AM To: Simon Lockhart Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem On Apr 26, 2020, at 20:04, Simon Lockhart > wrote: On 26 Apr 2020, at 17:50, Matthias Brumm > wrote: Do you have an ellaborated guess, how much computing power that would need? The billions of dollars/euros that will be generated from the creation of IPv4+ will fund the massive server infrastructure. And all the profit from Great New Spam filter would be dedicated to get rid of COVID-19. Right, Elad?.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From campbell at inca.ie Sun Apr 26 23:50:22 2020 From: campbell at inca.ie (Ed Campbell) Date: Sun, 26 Apr 2020 22:50:22 +0100 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: Message-ID: So you have a solution for Google and Facebook too then? Smh. Sent from my iPhone > On 26 Apr 2020, at 22:36, Elad Cohen wrote: > > ? > According to the following link, which is a presentation that Spamhaus wrote on themselves and showed in a private event, Spamhaus is receiving high amount of illegaly-obtained privacy data of internet users from their contacts inside internet organizations and internet companies, and then (according to their presentation) they share it in illegal way without any warrant with law enforcement agencies, this is completely illegal because it is done in a systematic regular way, this is the reason that they are keeping their anonymity, this is the reason that Law Enforcement Agencies are doing nothing regarding Spamhaus (because Spamhaus is providing them on a regular basis and in a systematic methods - massive amount of illegaly-obtained intelligence data) despite all the many complaints worldwide against Spamhaus. > > https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation > > The author of that private presentation as written in it is Richard D G Cox who was the co-chair of the ripe anti-abuse working group, there are more secret contacts of Spamhaus inside Ripe just like Richard D G Cox was, they are usually the ones that are trying to manipulate public opinion without any single proof, just like was done against me today. > > These people (Spamhaus secret contacts just like Richard D G Cox was) are bringing politics inside internet organizations, create cyber influence operations, targeting the people that they cannot control and so on. Spamhaus is an highly illegal anonymous organization and the above presentation link shows it in their own words. > > Respectfully, > Elad > From: Ed Campbell > Sent: Monday, April 27, 2020 12:25 AM > To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem > > Where is the proof that Spamhaus, an UK organization, are illegal or are ran by a mob? Hopefully you don?t mean that Illinois court ruling? Without a court ruling on this that is also defamation. > > Perhaps we can stick to what this list is for, rather than making silly accusations. > > Sent from my iPhone > >>> On 26 Apr 2020, at 21:58, Elad Cohen wrote: >>> >> ? >> The spamhaus fans just cannot sit quietly in their corner. >> >> "I know you will find again great words to reply" >> >> If you wish. >> >> I'm willing to have a discussion with anyone, but a constructive discussion, not a discussion with people which have hidden interests, with people that were sent by candidates (and candidates themselves that are showing up here and yelling), not with people that their actions is due to fear. >> >> I'm not fighting everyone, on the contrary - If I will have the honor of being elected, you can be sure that I will fight for the interests of each and every one of you. >> >> I only asked the illegal anonymous organization spamhaus fans to be quiet if they want me to post my last technical solution and they know exactly who they are, I respect everyone else and I respect Ripe. >> >> >> Regarding the "leadership qualities" that you are referring to, I definitely not have the "leadership qualities" of our Chairman as was written about him here: >> https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html >> >> But there is only one problem with it, when our board member Maria pasted to the textarea the text that our Chairman wrote on himself and sent to her - she forgot to remove the title from it, so this is what we see in the above link: >> >> "Reason for nominating the candidate: >> Reason for nominating the candidate: " >> >> the second same title is because a copy-paste was done here, our Chairman, 15 minutes after he nominated Maria with a single sentence - sent a whole paragraph on himself to Maria for her to use it when she nominated him, this is what our Chairman wrote on himself: (among other things in the whole paragraph in the link above) >> "Christian has shown very strong and positive leadership in his role as chair of the board" >> >> If that is what our Chairman and our Board member are doing behind the scenes (Maria cheated the community that these are her words while she didn't even read it, she did only copy-paste), we cannot trust them with managing Ripe expenses and the fact is that thy are denying to reveal detailed financial information and they are denying detailed transparency. >> >> so I lack that kind of "leadership qualities" , I do have other leadership qualities - I stood up against "The Spamhaus Project - something that only few dare to do, I'm taking the heat from you each and every day but still it doesn't impact me a bit, yesterday here I stood up against a group of IPv6 deployers that have an interest that IPv4+ will not be implemented - but we all truly know (just like the very vast majority of the internet community) that it is the right thing to do, I stood up against them all, alone. >> >> >> Regarding your last paragraph: >> >> "All I can see is a guy, who tries to get elected because he really desperately needs something in his CV, and because the chances might be thin (you haven't even bothered to bring any CV or something up, while at least 3 candidates actually put in the effort so we can judge what they have done in the past. You share nothing of your past, what you have done, where you have participated. instead you try to push your campaign by pushing your own ideas on an unsuitable platform." >> >> I will not answer that paragraph because of the way that it is written, you just displayed yourself in it at the darkest distorted light. Where did you see that I'm trying to be elected ? did you see me jumping into other discussion lists and start yelling on candidates ? (like was done here) - do you want me to write about myself like our Chairman did ? I believe in taking the right actions, not in creating the right connections. This is not a campaign - this is me showing my ideas to the community before they will be implemented. I don't believe in living in the past and I personally dislike any kind of bragging. Don't you care about what a candidate will do if and after it will be chosen ? this I didn't hear from anyone. People only know how to talk about themselves. No worries, you will know exactly what are my plans for Ripe and you can be sure that if I will be elected I will take Ripe to its golden age - and each and every LIR member will enjoy from it, until the last one. >> >> Silvan, you are obviously supporting another candidate, you shouldn't fear from me, I come with open hands and with a clean heart. >> >> Respectfully, >> Elad >> From: members-discuss on behalf of Silvan Gebhardt >> Sent: Sunday, April 26, 2020 10:31 PM >> To: members-discuss at ripe.net >> Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem >> >> Hi Elad, it's me again, one of your favourite illegals. >> >> >> >> >> >> >> >> You are a candidate for the Board of RIPE. >> >> as a RIPE board member you should be able to actually have a discussion with people, to engage in disputes in a constructive way, instead you instantly pick a fight, and try to fight everyone who does not agree with your points. >> >> You ask that Members here - which are most likely other members of LIRS which have as much a right to state their opinion, "stay quiet" - or you suggest to remove them from the mailinglist. >> >> >> This clearly does not look good for you, Elad - leave the accusations away, you are definitely not displaying any leadership qualities which would be required as board of RIPE. >> >> >> So, accusations against you, you ask for proof. >> >> You yourself state accusations against RIPE Board ("corruption") but you do not provide any proof. >> >> All I can see is a guy, who tries to get elected because he really desperately needs something in his CV, and because the chances might be thin (you haven't even bothered to bring any CV or something up, while at least 3 candidates actually put in the effort so we can judge what they have done in the past. You share nothing of your past, what you have done, where you have participated. instead you try to push your campaign by pushing your own ideas on an unsuitable platform. >> >> I agree that "even bad publicity can be some publicity" - but it will not help you on your election because at this rate, the only vote you get is your own word. >> >> >> >> >> >> I know you will find again great words to reply, it will greatly amuse me. >> >> >> >> >> >> trust me, if you start picking fights with everyone, people will start digging and open up a case with the arbiter under clause 1.2.1.1 section 2 >> >> >> >>> On 4/26/20 7:15 PM, Elad Cohen wrote: >>> If the Spamhaus fans will be quiet in their corner then tomorrow will be the last technical solution. >>> >>> Respectfully, >>> Elad >>> From: Darren Brown >>> Sent: Sunday, April 26, 2020 10:13 PM >>> To: Elad Cohen ; href ; members-discuss at ripe.net >>> Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem >>> >>> Elad it?s great you have so many ideas but this is getting a bit silly now, go and take a break , have a drink and put in a film. It?s Sunday evening , chill out >>> >>> Regards >>> Darren >>> >>> Get Outlook for iOS >>> From: members-discuss on behalf of Elad Cohen >>> Sent: Sunday, April 26, 2020 8:09:09 PM >>> To: href ; members-discuss at ripe.net >>> Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem >>> >>> "I had no idea that you may have been involved in the Cape Town hijack!" >>> >>> The cyber influence operation continue... complete lies without a single proof, can anyone show a single proof ? >>> >>> Are you so scared from me being elected ? that you need to spread lies ? >>> >>> I'm highly honored that the illegal anonymous organization "The Spamhaus Project" decided to attack me, it means a lot. >>> >>> Lets see who is the Spamhaus fan that will jump now. >>> >>> Respectfully, >>> Elad >>> From: href >>> Sent: Sunday, April 26, 2020 10:01 PM >>> To: Elad Cohen ; members-discuss at ripe.net >>> Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem >>> >>> Elad, >>> >>> >>> >>> Some members sent some additional information about you: I can now understand your replies: I had no idea that you may have been involved in the Cape Town hijack! >>> >>> >>> >>> Please forget about my badly chosen example. Accusations aside, it is time to get serious and I'll re-iterate my original question: what are your thoughts and technical solutions about IP hijacking (not the Cape town one) ? >>> >>> >>> >>> >>> >>>> On 4/26/20 8:23 PM, Elad Cohen wrote: >>>> Jordan, >>>> >>>> What you are writing is false, telling a lie again and again will not make it truth. >>>> >>>> "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) >>>> >>>> And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: >>>> >>>> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >>>> >>>> "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. >>>> >>>> ---- >>>> >>>> Can you show a single proof to what you are writing? You are taking part in an illegal cyber influence operation against me. >>>> >>>> Respectfully, >>>> Elad >>>> >>>> From: Jordan Bracco >>>> Sent: Sunday, April 26, 2020 9:14 PM >>>> To: Elad Cohen ; members-discuss at ripe.net >>>> Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem >>>> >>>> Elad, >>>> >>>> I do not see what you mean by "telling a lie again and again". I have a vague memory of something fishy going on with a Cape Town ip block, but there was many occurences like this. I cited Cape Town as an example. I do not have proof, so maybe the Cape Town is a false memory, but IP hijacking (which was the subject of my email, not Cape Town) surely do happen. >>>> >>>> For the rest of your reply-- I just simply do not understand it. >>>> >>>> - I fail to see a correlation between hijacking IP space and Spamhaus. Could you please enlighten me ? >>>> - I also fail to understand what you mean by "mob friends just like you". I have no relationship whatsoever with SpamHaus, I do not use their DNSBLs (as I delegate most of my emails to Fastmail). >>>> >>>> I was just asking for your thoughts and technical solutions to IP space hijacking. Your reply turned into a rant about Spamhaus (?) and accusing me of being "mob friend" of it (?) ? >>>> >>>> On Sun, Apr 26, 2020, at 19:46, Elad Cohen wrote: >>>>> Jordan, >>>>> >>>>> What you are writing is false, telling a lie again and again will not make it truth. >>>>> >>>>> "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) >>>>> >>>>> And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: >>>>> >>>>> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >>>>> >>>>> "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. >>>>> >>>>> Respectfully, >>>>> Elad >>>>> >>>>> >>>>> >>>>> From: members-discuss on behalf of Jordan Bracco >>>>> Sent: Sunday, April 26, 2020 8:23 PM >>>>> To: members-discuss at ripe.net >>>>> Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem >>>>> >>>>> Dear Elad, >>>>> >>>>> Unrelated to the spam proposal-- but have you found a technical solution to avoid malicious third parties to hijack assigned IP space (for example, if I remember that there was some IP space from Cape Town city that got hijacked). What are you thoughts on this, and your technical solution to it ? >>>>> >>>>> >>>>>> On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: >>>>>> Hello Everyone, >>>>>> >>>>>> I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). >>>>>> >>>>>> Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". >>>>>> >>>>>> >>>>>> The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: >>>>>> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >>>>>> >>>>>> >>>>>> >>>>>> The Implementation: >>>>>> >>>>>> There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. >>>>>> >>>>>> Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). >>>>>> >>>>>> After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). >>>>>> >>>>>> In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. >>>>>> >>>>>> The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). >>>>>> >>>>>> The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). >>>>>> >>>>>> The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). >>>>>> >>>>>> The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. >>>>>> >>>>>> >>>>>> >>>>>> The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): >>>>>> >>>>>> - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. >>>>>> >>>>>> - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. >>>>>> >>>>>> - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). >>>>>> >>>>>> - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). >>>>>> >>>>>> - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. >>>>>> >>>>>> - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. >>>>>> >>>>>> - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: >>>>>> >>>>>> - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. >>>>>> >>>>>> - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Whitelist Handshake: >>>>>> >>>>>> - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. >>>>>> >>>>>> - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc >>>>>> >>>>>> - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). >>>>>> >>>>>> >>>>>> Notification of spam emails: >>>>>> >>>>>> - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). >>>>>> >>>>>> >>>>>> >>>>>> Email Spoofing: >>>>>> >>>>>> - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. >>>>>> >>>>>> - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. >>>>>> >>>>>> - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. >>>>>> >>>>>> - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. >>>>>> >>>>>> >>>>>> >>>>>> Security Aspects: >>>>>> >>>>>> - All stored data in NoSpam.org Backend infrastructure is hashed. >>>>>> >>>>>> - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. >>>>>> >>>>>> - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. >>>>>> >>>>>> - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). >>>>>> >>>>>> - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. >>>>>> >>>>>> >>>>>> To make it short: >>>>>> >>>>>> - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). >>>>>> >>>>>> - Any email message from an email address or domain in whitelist - will reach the inbox. >>>>>> >>>>>> - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. >>>>>> >>>>>> - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. >>>>>> >>>>>> - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. >>>>>> >>>>>> - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. >>>>>> >>>>>> >>>>>> >>>>>> Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. >>>>>> >>>>>> >>>>>> Respectfully, >>>>>> Elad >>>>>> >>>>>> _______________________________________________ >>>>>> members-discuss mailing list >>>>>> members-discuss at ripe.net >>>>>> https://lists.ripe.net/mailman/listinfo/members-discuss >>>>>> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net >>>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> members-discuss mailing list >>> members-discuss at ripe.net >>> https://lists.ripe.net/mailman/listinfo/members-discuss >>> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/silvan%40unavailable.online >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at cynthia.re Mon Apr 27 00:02:59 2020 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Mon, 27 Apr 2020 00:02:59 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails Message-ID: Hello, I would like to request that Elad Cohen be blocked from sending to the members-discuss mailing lists after multiple offtopic threads started by Elad and the personal attacks and ignoring WG chairs telling Elad to stop. I would further like to point out that as he is a confirmed candidate for the Exec Board, one of his key responsibilities would be to have the "Ability to communicate effectively", which he has shown that he is not capable of. I would personally say that elad lacks most of the expectations listed on https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations . I would like to propose that the RIPE NCC ban Elad Cohen from interacting with the RIPE Community (via Meetings or mailing lists) due to his blatant disregard for the Code of Conduct and for being hostile towards others in the community. As the RIPE NCC hosts and manages these lists I think the RIPE NCC has a responsibility to keep the lists professional and to remove those who repeatedly ignore what the WG chairs are saying. - Cynthia -------------- next part -------------- An HTML attachment was scrubbed... URL: From alistair at conplex.io Mon Apr 27 00:14:49 2020 From: alistair at conplex.io (Alistair Mackenzie) Date: Sun, 26 Apr 2020 22:14:49 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: Message-ID: <01020171b88eaa0d-5c91c841-4e97-4fd0-a6ca-e92f9db60135-000000@eu-west-1.amazonses.com> Hi, I do think we should at the very least moderate posts made by Elad due to the complete lack of respect towards the community as a whole and also, the disregard for the Code of Conduct Cynthia mentions. For reference see the emails to various WGs are below. https://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-April/013159.html https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2020-April/005662.html https://www.ripe.net/ripe/mail/archives/connect-wg/2020-April/000103.html https://www.ripe.net/ripe/mail/archives/cooperation-wg/2020-April/001384.html https://www.ripe.net/ripe/mail/archives/iot-wg/2020-April/000476.html https://www.ripe.net/ripe/mail/archives/mat-wg/2020-April/000873.html https://www.ripe.net/ripe/mail/archives/opensource-wg/2020-April/000092.html https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2020-April/003336.html This behavior from Elad is not just here on RIPE mailing lists, it has been seen elsewhere such as NANOG. Alistair On 26/04/2020 23:02, Cynthia Revstr?m wrote: > Hello, > > I would like to request that Elad Cohen be blocked from sending to the > members-discuss mailing lists after multiple offtopic threads started by > Elad and the personal attacks and ignoring WG chairs telling Elad to stop. > > I would further like to point out that as he is a confirmed candidate > for the Exec Board, one of his key responsibilities would be to have the > "Ability to communicate effectively", which he has shown that he is not > capable of. > I would personally say that elad lacks most of the expectations listed > on?https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations. > > I would like to propose?that the RIPE NCC ban Elad Cohen from > interacting with the RIPE Community (via Meetings or mailing lists) due > to his blatant disregard for the Code of Conduct and for being hostile > towards others in the community. As the RIPE NCC hosts and manages these > lists I think the RIPE NCC has a responsibility to keep the lists > professional and to remove those who repeatedly ignore?what the WG > chairs are saying. > > - Cynthia > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/alistair%40conplex.io > From Hans.Govenius at devnet.fi Mon Apr 27 00:16:10 2020 From: Hans.Govenius at devnet.fi (Hans Govenius) Date: Sun, 26 Apr 2020 22:16:10 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: Message-ID: <4034607097129641A4150790179904F5B2E41C80@ex10mdb8.wmhost.com> Hello This is ridiculous and out of the question. Its completely out of order to even discuss such actions. These points which he brings to the discussion are atleast somewhat within the scope of matters that could be discussed on a Ripe members list. Its not like Elad would be speaking of ice bears or meatballs here. If someone does not like to discuss things ? get out of the list. Its that simple. I don?t take any position on these spam or ipv matters as I don?t have sufficient technical knowledge to either disagree or agree with them but its great that someone tries to come up with something and also I usually prefer if people try to advance things rather than block them. Now lets everyone be civil here and give everyone a voice. br. Hans L?hett?j?: members-discuss Puolesta Cynthia Revstr?m L?hetetty: maanantai 27. huhtikuuta 2020 1.03 Vastaanottaja: members-discuss at ripe.net; RIPE NCC Support Aihe: [members-discuss] Regarding Elad Cohen's nomination and emails Hello, I would like to request that Elad Cohen be blocked from sending to the members-discuss mailing lists after multiple offtopic threads started by Elad and the personal attacks and ignoring WG chairs telling Elad to stop. I would further like to point out that as he is a confirmed candidate for the Exec Board, one of his key responsibilities would be to have the "Ability to communicate effectively", which he has shown that he is not capable of. I would personally say that elad lacks most of the expectations listed on https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations. I would like to propose that the RIPE NCC ban Elad Cohen from interacting with the RIPE Community (via Meetings or mailing lists) due to his blatant disregard for the Code of Conduct and for being hostile towards others in the community. As the RIPE NCC hosts and manages these lists I think the RIPE NCC has a responsibility to keep the lists professional and to remove those who repeatedly ignore what the WG chairs are saying. - Cynthia -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Mon Apr 27 00:17:10 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 22:17:10 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: Message-ID: Hello, Cynthia is writing complete lies, everything that I wrote was on-topic and was related to the near general meeting that I'm interested to present in it all my ideas that I showed here. This mailing list is also for subjects related to the General Meeting and so I did. Cynthia is trying to have me out of the list because she is supporting another candidate. I didn't personally attack anyone, I always only replied to personal attacks on me, just like that personal attack from Cynthia on me. Regarding what Cynthia wrote: "I would personally say that elad lacks most of the expectations listed on" - this is a complete lie, she doesn't know me and I actually have vast experience regarding all of the the expectations. Respectfully, Elad ________________________________ From: members-discuss on behalf of Cynthia Revstr?m Sent: Monday, April 27, 2020 1:02 AM To: members-discuss at ripe.net ; RIPE NCC Support Subject: [members-discuss] Regarding Elad Cohen's nomination and emails Hello, I would like to request that Elad Cohen be blocked from sending to the members-discuss mailing lists after multiple offtopic threads started by Elad and the personal attacks and ignoring WG chairs telling Elad to stop. I would further like to point out that as he is a confirmed candidate for the Exec Board, one of his key responsibilities would be to have the "Ability to communicate effectively", which he has shown that he is not capable of. I would personally say that elad lacks most of the expectations listed on https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations. I would like to propose that the RIPE NCC ban Elad Cohen from interacting with the RIPE Community (via Meetings or mailing lists) due to his blatant disregard for the Code of Conduct and for being hostile towards others in the community. As the RIPE NCC hosts and manages these lists I think the RIPE NCC has a responsibility to keep the lists professional and to remove those who repeatedly ignore what the WG chairs are saying. - Cynthia -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Mon Apr 27 00:22:10 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 22:22:10 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <01020171b88eaa0d-5c91c841-4e97-4fd0-a6ca-e92f9db60135-000000@eu-west-1.amazonses.com> References: , <01020171b88eaa0d-5c91c841-4e97-4fd0-a6ca-e92f9db60135-000000@eu-west-1.amazonses.com> Message-ID: Hello, I was the one being attacked in the Ripe working groups and I only provide an official single response after being attacked for many months. Regarding: " it has been seen elsewhere such as NANOG." - this is a complete lie - Can you provide a single link to Nanog ? I was attacked there by the same illegal anonymous organization "The Spamhaus Project" and there I didn't provide a full official response. Alistair, I didn't hear your voice when I was attacked here initially in the Anti-Abuse Working Group, so your interests are not pure. Respectfully, Elad ________________________________ From: members-discuss on behalf of Alistair Mackenzie Sent: Monday, April 27, 2020 1:14 AM To: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hi, I do think we should at the very least moderate posts made by Elad due to the complete lack of respect towards the community as a whole and also, the disregard for the Code of Conduct Cynthia mentions. For reference see the emails to various WGs are below. https://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-April/013159.html https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2020-April/005662.html https://www.ripe.net/ripe/mail/archives/connect-wg/2020-April/000103.html https://www.ripe.net/ripe/mail/archives/cooperation-wg/2020-April/001384.html https://www.ripe.net/ripe/mail/archives/iot-wg/2020-April/000476.html https://www.ripe.net/ripe/mail/archives/mat-wg/2020-April/000873.html https://www.ripe.net/ripe/mail/archives/opensource-wg/2020-April/000092.html https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2020-April/003336.html This behavior from Elad is not just here on RIPE mailing lists, it has been seen elsewhere such as NANOG. Alistair On 26/04/2020 23:02, Cynthia Revstr?m wrote: > Hello, > > I would like to request that Elad Cohen be blocked from sending to the > members-discuss mailing lists after multiple offtopic threads started by > Elad and the personal attacks and ignoring WG chairs telling Elad to stop. > > I would further like to point out that as he is a confirmed candidate > for the Exec Board, one of his key responsibilities would be to have the > "Ability to communicate effectively", which he has shown that he is not > capable of. > I would personally say that elad lacks most of the expectations listed > on https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations. > > I would like to propose that the RIPE NCC ban Elad Cohen from > interacting with the RIPE Community (via Meetings or mailing lists) due > to his blatant disregard for the Code of Conduct and for being hostile > towards others in the community. As the RIPE NCC hosts and manages these > lists I think the RIPE NCC has a responsibility to keep the lists > professional and to remove those who repeatedly ignore what the WG > chairs are saying. > > - Cynthia > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/alistair%40conplex.io > _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/elad%40netstyle.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at cynthia.re Mon Apr 27 00:24:49 2020 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Mon, 27 Apr 2020 00:24:49 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: Message-ID: I would also like to formally request that the RIPE NCC investigate if Elad Cohen has breached A.1.2.2.B of RIPE-716. https://www.ripe.net/publications/docs/ripe-716#a122b This is with regards to statements like this: "Ripe have 30 millions euros of expenses each year that are hidden and now shown to where exactly they are paid, instead of that corruption" I believe that he does indeed make unreasonable allegations towards the RIPE NCC to damage it's reputation. - Cynthia On Mon, Apr 27, 2020 at 12:02 AM Cynthia Revstr?m wrote: > Hello, > > I would like to request that Elad Cohen be blocked from sending to the > members-discuss mailing lists after multiple offtopic threads started by > Elad and the personal attacks and ignoring WG chairs telling Elad to stop. > > I would further like to point out that as he is a confirmed candidate for > the Exec Board, one of his key responsibilities would be to have the > "Ability to communicate effectively", which he has shown that he is not > capable of. > I would personally say that elad lacks most of the expectations listed on > https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations > . > > I would like to propose that the RIPE NCC ban Elad Cohen from interacting > with the RIPE Community (via Meetings or mailing lists) due to his blatant > disregard for the Code of Conduct and for being hostile towards others in > the community. As the RIPE NCC hosts and manages these lists I think the > RIPE NCC has a responsibility to keep the lists professional and to remove > those who repeatedly ignore what the WG chairs are saying. > > - Cynthia > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at cynthia.re Mon Apr 27 00:31:18 2020 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Mon, 27 Apr 2020 00:31:18 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: Message-ID: Hello, > This mailing list is also for subjects related to the General Meeting and so I did. how is email spam related to the general meeting? > Cynthia is trying to have me out of the list because she is supporting another candidate. I am not supporting any particular candidate, but I will say that I would prefer literally any candidate over you. > "I would personally say that elad lacks most of the expectations listed on" - this is a complete lie, she doesn't know me and I actually have vast experience regarding all of the the expectations. I would like to say that you have shown that you do not have the "Ability to communicate effectively" expectation nailed down. - Cynthia On Mon, Apr 27, 2020 at 12:17 AM Elad Cohen wrote: > Hello, > > Cynthia is writing complete lies, everything that I wrote was on-topic and > was related to the near general meeting that I'm interested to present in > it all my ideas that I showed here. This mailing list is also for subjects > related to the General Meeting and so I did. > > Cynthia is trying to have me out of the list because she is supporting > another candidate. > > I didn't personally attack anyone, I always only replied to personal > attacks on me, just like that personal attack from Cynthia on me. > > Regarding what Cynthia wrote: > "I would personally say that elad lacks most of the expectations listed > on" - this is a complete lie, she doesn't know me and I actually have vast > experience regarding all of the the expectations. > > Respectfully, > Elad > ------------------------------ > *From:* members-discuss on behalf of > Cynthia Revstr?m > *Sent:* Monday, April 27, 2020 1:02 AM > *To:* members-discuss at ripe.net ; RIPE NCC > Support > *Subject:* [members-discuss] Regarding Elad Cohen's nomination and emails > > Hello, > > I would like to request that Elad Cohen be blocked from sending to the > members-discuss mailing lists after multiple offtopic threads started by > Elad and the personal attacks and ignoring WG chairs telling Elad to stop. > > I would further like to point out that as he is a confirmed candidate for > the Exec Board, one of his key responsibilities would be to have the > "Ability to communicate effectively", which he has shown that he is not > capable of. > I would personally say that elad lacks most of the expectations listed on > https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations > . > > I would like to propose that the RIPE NCC ban Elad Cohen from interacting > with the RIPE Community (via Meetings or mailing lists) due to his blatant > disregard for the Code of Conduct and for being hostile towards others in > the community. As the RIPE NCC hosts and manages these lists I think the > RIPE NCC has a responsibility to keep the lists professional and to remove > those who repeatedly ignore what the WG chairs are saying. > > - Cynthia > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Mon Apr 27 00:38:32 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 22:38:32 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: , Message-ID: When I was first initially attacked in Ripe by your colleague from "The Spamhaus Project", you didn't raise your voice. Email spam is my idea and I'm a candidate and I want to show a presentation of it in the general meeting, OK ? You are the one that cannot communicate effectively and only attacking me due to fear. It's a bit strange, that you started to attack me here immediately after I shared the presentation of "The Spamhaus Project", and you are also a "security researcher" like them all... Respectfully, Elad ________________________________ From: Cynthia Revstr?m Sent: Monday, April 27, 2020 1:31 AM To: Elad Cohen Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hello, > This mailing list is also for subjects related to the General Meeting and so I did. how is email spam related to the general meeting? > Cynthia is trying to have me out of the list because she is supporting another candidate. I am not supporting any particular candidate, but I will say that I would prefer literally any candidate over you. > "I would personally say that elad lacks most of the expectations listed on" - this is a complete lie, she doesn't know me and I actually have vast experience regarding all of the the expectations. I would like to say that you have shown that you do not have the "Ability to communicate effectively" expectation nailed down. - Cynthia On Mon, Apr 27, 2020 at 12:17 AM Elad Cohen > wrote: Hello, Cynthia is writing complete lies, everything that I wrote was on-topic and was related to the near general meeting that I'm interested to present in it all my ideas that I showed here. This mailing list is also for subjects related to the General Meeting and so I did. Cynthia is trying to have me out of the list because she is supporting another candidate. I didn't personally attack anyone, I always only replied to personal attacks on me, just like that personal attack from Cynthia on me. Regarding what Cynthia wrote: "I would personally say that elad lacks most of the expectations listed on" - this is a complete lie, she doesn't know me and I actually have vast experience regarding all of the the expectations. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:02 AM To: members-discuss at ripe.net >; RIPE NCC Support > Subject: [members-discuss] Regarding Elad Cohen's nomination and emails Hello, I would like to request that Elad Cohen be blocked from sending to the members-discuss mailing lists after multiple offtopic threads started by Elad and the personal attacks and ignoring WG chairs telling Elad to stop. I would further like to point out that as he is a confirmed candidate for the Exec Board, one of his key responsibilities would be to have the "Ability to communicate effectively", which he has shown that he is not capable of. I would personally say that elad lacks most of the expectations listed on https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations. I would like to propose that the RIPE NCC ban Elad Cohen from interacting with the RIPE Community (via Meetings or mailing lists) due to his blatant disregard for the Code of Conduct and for being hostile towards others in the community. As the RIPE NCC hosts and manages these lists I think the RIPE NCC has a responsibility to keep the lists professional and to remove those who repeatedly ignore what the WG chairs are saying. - Cynthia -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvan at unavailable.online Mon Apr 27 00:35:54 2020 From: silvan at unavailable.online (Silvan Gebhardt) Date: Sun, 26 Apr 2020 22:35:54 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <4034607097129641A4150790179904F5B2E41C80@ex10mdb8.wmhost.com> References: <4034607097129641A4150790179904F5B2E41C80@ex10mdb8.wmhost.com> Message-ID: <0c470660-013c-242b-4fef-2e963f06b415@unavailable.online> Hello Hans, Have you looked at the links alistair posted, let's pick this: https://www.ripe.net/ripe/mail/archives/cooperation-wg/2020-April/001384.html here Elad both insults people constnatly in this thread, and showing screenshots of where he "indentified people as antisemits" - and shows as "Proof" another email, with no source, so for all we know, Elad has written himself. https://imgur.com/a/Rzrbxkz <- so he produces his own "proofs" And why do I think Elad wrote that himself? because he has been called out on his IP adress missapropriation as you can see, if you read this. And this level as shown in this imgur link is beyond waht's acceptable. So he produces his own sources, where he does personally affect peoples to the level of calling things. I have to disagree with you, I consider Elad as harmful and personally attacking people constantly. I do support the stance of Cynthia here and hope the RIPE community can take a stance here against the bullying of Elad. I've seen how things progressed here, from a ususal trolling because people did not take any of Elads proposal serious as they very - in my personal opinion - over the top. But it has progressed to Elad attacking people on a level that is not acceptable for this community. I would again like to stress that Elad wants to be elected as RIPE chair. So are we, as a community, remotely considering someone with this singificant bullying behaviour into a chair of RIPE? Someone who calls everyone that does not agree with his opinion illegal, and beeing engaged in illegal options, and he also refers to mental health of others, as seen in other On 4/26/20 10:16 PM, Hans Govenius wrote: > > Hello > > ? > > This is ridiculous and out of the question. > > ? > > Its completely out of order to even discuss such actions. > > ? > > These points which he brings to the discussion are atleast somewhat > within the scope of matters that could be discussed on a Ripe members > list. Its not like Elad would be speaking of ice bears or meatballs here. > > ? > > If someone does not like to discuss things ? get out of the list. Its > that simple. > > ? > > I don?t take any position on these spam or ipv matters as I don?t have > sufficient technical knowledge to either disagree or agree with them > but its great that someone tries to come up with something and also I > usually prefer if people try to advance things rather than block them. > > ? > > ? > > Now lets everyone be civil here and give everyone a voice. > > ? > > ? > > br. Hans > > ? > > ? > > *L?hett?j?:* members-discuss > *Puolesta *Cynthia Revstr?m > *L?hetetty:* maanantai 27. huhtikuuta 2020 1.03 > *Vastaanottaja:* members-discuss at ripe.net; RIPE NCC Support > *Aihe:* [members-discuss] Regarding Elad Cohen's nomination and emails > > ? > > Hello, > > ? > > I would like to request that Elad Cohen be blocked from sending to the > members-discuss mailing lists after multiple offtopic threads started > by Elad and the personal attacks and ignoring WG chairs telling Elad > to stop. > > ? > > I would further like to point out that as he is a confirmed candidate > for the Exec Board, one of his key responsibilities would be to have > the "Ability to communicate effectively", which he has shown that he > is not capable of. > > I would personally say that elad lacks most of the expectations listed > on?https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations. > > ? > > I would like to propose?that the RIPE NCC ban Elad Cohen from > interacting with the RIPE Community (via Meetings or mailing lists) > due to his blatant disregard for the Code of Conduct and for being > hostile towards others in the community. As the RIPE NCC hosts and > manages these lists I think the RIPE NCC has a responsibility to keep > the lists professional and to remove those who repeatedly ignore?what > the WG chairs are saying. > > ? > > - Cynthia > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/silvan%40unavailable.online -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmarsden at arctarus.co.uk Mon Apr 27 00:44:03 2020 From: jmarsden at arctarus.co.uk (Joseph Marsden) Date: Sun, 26 Apr 2020 23:44:03 +0100 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: Message-ID: <2a4c0584-a1ef-7470-b12c-7649fca77205@marsden.space> I support Cynthia's request for a formal investigation. Best Joseph On 26/04/2020 23:24, Cynthia Revstr?m wrote: > I would also like to formally request that the RIPE NCC investigate if > Elad Cohen has breached A.1.2.2.B of RIPE-716. > https://www.ripe.net/publications/docs/ripe-716#a122b > This is with regards to statements like this: > "Ripe have 30 millions euros of expenses each year that are hidden and > now shown to where exactly they are paid, instead of that corruption" > > I believe that he does indeed make unreasonable allegations towards > the RIPE NCC to damage it's reputation. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:02 AM Cynthia Revstr?m > wrote: > > Hello, > > I would like to request that Elad Cohen be blocked from sending to > the members-discuss mailing lists after multiple offtopic threads > started by Elad and the personal attacks and ignoring WG chairs > telling Elad to stop. > > I would further like to point out that as he is a confirmed > candidate for the Exec Board, one of his key responsibilities > would be to have the "Ability to communicate effectively", which > he has shown that he is not capable of. > I would personally say that elad lacks most of the expectations > listed > on?https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations. > > I would like to propose?that the RIPE NCC ban Elad Cohen from > interacting with the RIPE Community (via Meetings or mailing > lists) due to his blatant disregard for the Code of Conduct and > for being hostile towards others in the community. As the RIPE NCC > hosts and manages these lists I think the RIPE NCC has a > responsibility to keep the lists professional and to remove those > who repeatedly ignore?what the WG chairs are saying. > > - Cynthia > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/joseph%40arctarus.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Mon Apr 27 00:48:40 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 22:48:40 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <0c470660-013c-242b-4fef-2e963f06b415@unavailable.online> References: <4034607097129641A4150790179904F5B2E41C80@ex10mdb8.wmhost.com>, <0c470660-013c-242b-4fef-2e963f06b415@unavailable.online> Message-ID: This was my official response after many months of me being attacked also here in Ripe and Nanog by a sick member of "The Spamhaus Project" and after I was called in many worst names. After many months I provided an official response. The source there is Nanog and this is how the sick member of "The Spamhaus Project" was called by a poster in Nanog which is not related to me. Silvan Gabhardt is clearly a member of "The Spamhaus Project" and trying to change the facts, just like "The Spamhaus Project" are doing in their illegal cyber influence operations. Respectfully, Elad ________________________________ From: members-discuss on behalf of Silvan Gebhardt Sent: Monday, April 27, 2020 1:35 AM To: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hello Hans, Have you looked at the links alistair posted, let's pick this: https://www.ripe.net/ripe/mail/archives/cooperation-wg/2020-April/001384.html here Elad both insults people constnatly in this thread, and showing screenshots of where he "indentified people as antisemits" - and shows as "Proof" another email, with no source, so for all we know, Elad has written himself. https://imgur.com/a/Rzrbxkz <- so he produces his own "proofs" And why do I think Elad wrote that himself? because he has been called out on his IP adress missapropriation as you can see, if you read this. And this level as shown in this imgur link is beyond waht's acceptable. So he produces his own sources, where he does personally affect peoples to the level of calling things. I have to disagree with you, I consider Elad as harmful and personally attacking people constantly. I do support the stance of Cynthia here and hope the RIPE community can take a stance here against the bullying of Elad. I've seen how things progressed here, from a ususal trolling because people did not take any of Elads proposal serious as they very - in my personal opinion - over the top. But it has progressed to Elad attacking people on a level that is not acceptable for this community. I would again like to stress that Elad wants to be elected as RIPE chair. So are we, as a community, remotely considering someone with this singificant bullying behaviour into a chair of RIPE? Someone who calls everyone that does not agree with his opinion illegal, and beeing engaged in illegal options, and he also refers to mental health of others, as seen in other On 4/26/20 10:16 PM, Hans Govenius wrote: Hello This is ridiculous and out of the question. Its completely out of order to even discuss such actions. These points which he brings to the discussion are atleast somewhat within the scope of matters that could be discussed on a Ripe members list. Its not like Elad would be speaking of ice bears or meatballs here. If someone does not like to discuss things ? get out of the list. Its that simple. I don?t take any position on these spam or ipv matters as I don?t have sufficient technical knowledge to either disagree or agree with them but its great that someone tries to come up with something and also I usually prefer if people try to advance things rather than block them. Now lets everyone be civil here and give everyone a voice. br. Hans L?hett?j?: members-discuss Puolesta Cynthia Revstr?m L?hetetty: maanantai 27. huhtikuuta 2020 1.03 Vastaanottaja: members-discuss at ripe.net; RIPE NCC Support Aihe: [members-discuss] Regarding Elad Cohen's nomination and emails Hello, I would like to request that Elad Cohen be blocked from sending to the members-discuss mailing lists after multiple offtopic threads started by Elad and the personal attacks and ignoring WG chairs telling Elad to stop. I would further like to point out that as he is a confirmed candidate for the Exec Board, one of his key responsibilities would be to have the "Ability to communicate effectively", which he has shown that he is not capable of. I would personally say that elad lacks most of the expectations listed on https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations. I would like to propose that the RIPE NCC ban Elad Cohen from interacting with the RIPE Community (via Meetings or mailing lists) due to his blatant disregard for the Code of Conduct and for being hostile towards others in the community. As the RIPE NCC hosts and manages these lists I think the RIPE NCC has a responsibility to keep the lists professional and to remove those who repeatedly ignore what the WG chairs are saying. - Cynthia _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/silvan%40unavailable.online -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhr at fhrnet.eu Mon Apr 27 01:02:00 2020 From: fhr at fhrnet.eu (Filip Hruska) Date: Mon, 27 Apr 2020 01:02:00 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <2a4c0584-a1ef-7470-b12c-7649fca77205@marsden.space> References: <2a4c0584-a1ef-7470-b12c-7649fca77205@marsden.space> Message-ID: Hello all, I would like to voice my support for this. The amount of unprofessional conduct in the past 2 or 3 email chains is simply ridiculous and completely unacceptable. Thank you, Filip On 4/27/20 12:44 AM, Joseph Marsden wrote: > I support Cynthia's request for a formal investigation. > > Best > Joseph > > On 26/04/2020 23:24, Cynthia Revstr?m wrote: >> I would also like to formally request that the RIPE NCC investigate >> if Elad Cohen has breached A.1.2.2.B of RIPE-716. >> https://www.ripe.net/publications/docs/ripe-716#a122b >> This is with regards to statements like this: >> "Ripe have 30 millions euros of expenses each year that are hidden >> and now shown to where exactly they are paid, instead of that corruption" >> >> I believe that he does indeed make unreasonable allegations towards >> the RIPE NCC to damage it's reputation. >> >> - Cynthia >> >> On Mon, Apr 27, 2020 at 12:02 AM Cynthia Revstr?m > > wrote: >> >> Hello, >> >> I would like to request that Elad Cohen be blocked from sending >> to the members-discuss mailing lists after multiple offtopic >> threads started by Elad and the personal attacks and ignoring WG >> chairs telling Elad to stop. >> >> I would further like to point out that as he is a confirmed >> candidate for the Exec Board, one of his key responsibilities >> would be to have the "Ability to communicate effectively", which >> he has shown that he is not capable of. >> I would personally say that elad lacks most of the expectations >> listed on >> https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations. >> >> I would like to propose?that the RIPE NCC ban Elad Cohen from >> interacting with the RIPE Community (via Meetings or mailing >> lists) due to his blatant disregard for the Code of Conduct and >> for being hostile towards others in the community. As the RIPE >> NCC hosts and manages these lists I think the RIPE NCC has a >> responsibility to keep the lists professional and to remove those >> who repeatedly ignore?what the WG chairs are saying. >> >> - Cynthia >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/joseph%40arctarus.co.uk > > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/fhr%40fhrnet.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hans.Govenius at devnet.fi Mon Apr 27 01:07:15 2020 From: Hans.Govenius at devnet.fi (Hans Govenius) Date: Sun, 26 Apr 2020 23:07:15 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <0c470660-013c-242b-4fef-2e963f06b415@unavailable.online> References: <4034607097129641A4150790179904F5B2E41C80@ex10mdb8.wmhost.com> <0c470660-013c-242b-4fef-2e963f06b415@unavailable.online> Message-ID: <4034607097129641A4150790179904F5B2E42059@ex10mdb8.wmhost.com> Hello I am not even remotely interested about those links. I am not even remotely interested if any or all people on this list do different illegal or any actions. That is not any of my concern and I wont use my time to read them. Only the following matters: 1. People in general have right to opinions and right to express them. If they are deflamatory to the degree that they are illegal, which is a not easy to achieve it is the job of law enforcement and judicial institutions to look into those allegations and take necessary actions. Not Ripe as Ripe is an organization you are forced to be part of if you need ip resources. Therefore its not a club of people who wants to be together. 2. I have never before this day hard of this Elad and what I have now witnessed is more like that he is being unfairly attacked 3. Criticism and investigations are important. I did also at one point raise questions of RIPE?s finances which are not very transparent. If someone is critical towards spamhouse, I don?t see problem here. Its an opinion and as far as its not illegal it must be tolerated. I will not comment on this ridiculous matter anymore. Br. Hans L?hett?j?: members-discuss Puolesta Silvan Gebhardt L?hetetty: maanantai 27. huhtikuuta 2020 1.36 Vastaanottaja: members-discuss at ripe.net Aihe: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hello Hans, Have you looked at the links alistair posted, let's pick this: https://www.ripe.net/ripe/mail/archives/cooperation-wg/2020-April/001384.html here Elad both insults people constnatly in this thread, and showing screenshots of where he "indentified people as antisemits" - and shows as "Proof" another email, with no source, so for all we know, Elad has written himself. https://imgur.com/a/Rzrbxkz <- so he produces his own "proofs" And why do I think Elad wrote that himself? because he has been called out on his IP adress missapropriation as you can see, if you read this. And this level as shown in this imgur link is beyond waht's acceptable. So he produces his own sources, where he does personally affect peoples to the level of calling things. I have to disagree with you, I consider Elad as harmful and personally attacking people constantly. I do support the stance of Cynthia here and hope the RIPE community can take a stance here against the bullying of Elad. I've seen how things progressed here, from a ususal trolling because people did not take any of Elads proposal serious as they very - in my personal opinion - over the top. But it has progressed to Elad attacking people on a level that is not acceptable for this community. I would again like to stress that Elad wants to be elected as RIPE chair. So are we, as a community, remotely considering someone with this singificant bullying behaviour into a chair of RIPE? Someone who calls everyone that does not agree with his opinion illegal, and beeing engaged in illegal options, and he also refers to mental health of others, as seen in other On 4/26/20 10:16 PM, Hans Govenius wrote: Hello This is ridiculous and out of the question. Its completely out of order to even discuss such actions. These points which he brings to the discussion are atleast somewhat within the scope of matters that could be discussed on a Ripe members list. Its not like Elad would be speaking of ice bears or meatballs here. If someone does not like to discuss things ? get out of the list. Its that simple. I don?t take any position on these spam or ipv matters as I don?t have sufficient technical knowledge to either disagree or agree with them but its great that someone tries to come up with something and also I usually prefer if people try to advance things rather than block them. Now lets everyone be civil here and give everyone a voice. br. Hans L?hett?j?: members-discuss Puolesta Cynthia Revstr?m L?hetetty: maanantai 27. huhtikuuta 2020 1.03 Vastaanottaja: members-discuss at ripe.net; RIPE NCC Support Aihe: [members-discuss] Regarding Elad Cohen's nomination and emails Hello, I would like to request that Elad Cohen be blocked from sending to the members-discuss mailing lists after multiple offtopic threads started by Elad and the personal attacks and ignoring WG chairs telling Elad to stop. I would further like to point out that as he is a confirmed candidate for the Exec Board, one of his key responsibilities would be to have the "Ability to communicate effectively", which he has shown that he is not capable of. I would personally say that elad lacks most of the expectations listed on https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations. I would like to propose that the RIPE NCC ban Elad Cohen from interacting with the RIPE Community (via Meetings or mailing lists) due to his blatant disregard for the Code of Conduct and for being hostile towards others in the community. As the RIPE NCC hosts and manages these lists I think the RIPE NCC has a responsibility to keep the lists professional and to remove those who repeatedly ignore what the WG chairs are saying. - Cynthia _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/silvan%40unavailable.online -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at cynthia.re Mon Apr 27 01:11:08 2020 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Mon, 27 Apr 2020 01:11:08 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <4034607097129641A4150790179904F5B2E42059@ex10mdb8.wmhost.com> References: <4034607097129641A4150790179904F5B2E41C80@ex10mdb8.wmhost.com> <0c470660-013c-242b-4fef-2e963f06b415@unavailable.online> <4034607097129641A4150790179904F5B2E42059@ex10mdb8.wmhost.com> Message-ID: please do note that RIPE is a community. The RIPE NCC is who you get IP space from. - Cynthia On Mon, 27 Apr 2020, 01:07 Hans Govenius, wrote: > Hello > > > > I am not even remotely interested about those links. I am not even > remotely interested if any or all people on this list do different illegal > or any actions. That is not any of my concern and I wont use my time to > read them. > > > > Only the following matters: > > > > 1. People in general have right to opinions and right to express them. > If they are deflamatory to the degree that they are illegal, which is a not > easy to achieve it is the job of law enforcement and judicial institutions > to look into those allegations and take necessary actions. Not Ripe as Ripe > is an organization you are forced to be part of if you need ip resources. > Therefore its not a club of people who wants to be together. > 2. I have never before this day hard of this Elad and what I have now > witnessed is more like that he is being unfairly attacked > 3. Criticism and investigations are important. I did also at one point > raise questions of RIPE?s finances which are not very transparent. If > someone is critical towards spamhouse, I don?t see problem here. Its an > opinion and as far as its not illegal it must be tolerated. > > > > > > I will not comment on this ridiculous matter anymore. > > > > > > Br. Hans > > > > > > *L?hett?j?:* members-discuss *Puolesta > *Silvan Gebhardt > *L?hetetty:* maanantai 27. huhtikuuta 2020 1.36 > *Vastaanottaja:* members-discuss at ripe.net > *Aihe:* Re: [members-discuss] Regarding Elad Cohen's nomination and emails > > > > Hello Hans, > > > > Have you looked at the links alistair posted, > > let's pick this: > > > > https://www.ripe.net/ripe/mail/archives/cooperation-wg/2020-April/001384.html > > > > > > here Elad both insults people constnatly in this thread, and showing screenshots of where he "indentified people as antisemits" - and shows as "Proof" another email, with no source, so for all we know, Elad has written himself. https://imgur.com/a/Rzrbxkz <- so he produces his own "proofs" > > > > And why do I think Elad wrote that himself? because he has been called out on his IP adress missapropriation as you can see, if you read this. And this level as shown in this imgur link is beyond waht's acceptable. > > > > > > > > > > > > So he produces his own sources, where he does personally affect peoples to the level of calling things. > > > > > > > > > > I have to disagree with you, I consider Elad as harmful and personally attacking people constantly. I do support the stance of Cynthia here and hope the RIPE community can take a stance here against the bullying of Elad. > > > > > > I've seen how things progressed here, from a ususal trolling because people did not take any of Elads proposal serious as they very - in my personal opinion - over the top. > > > > But it has progressed to Elad attacking people on a level that is not acceptable for this community. > > > > I would again like to stress that Elad wants to be elected as RIPE chair. So are we, as a community, remotely considering someone with this singificant bullying behaviour into a chair of RIPE? Someone who calls everyone that does not agree with his opinion illegal, and beeing engaged in illegal options, and he also refers to mental health of others, as seen in other > > > > > > > > > > On 4/26/20 10:16 PM, Hans Govenius wrote: > > Hello > > > > This is ridiculous and out of the question. > > > > Its completely out of order to even discuss such actions. > > > > These points which he brings to the discussion are atleast somewhat within > the scope of matters that could be discussed on a Ripe members list. Its > not like Elad would be speaking of ice bears or meatballs here. > > > > If someone does not like to discuss things ? get out of the list. Its that > simple. > > > > I don?t take any position on these spam or ipv matters as I don?t have > sufficient technical knowledge to either disagree or agree with them but > its great that someone tries to come up with something and also I usually > prefer if people try to advance things rather than block them. > > > > > > Now lets everyone be civil here and give everyone a voice. > > > > > > br. Hans > > > > > > *L?hett?j?:* members-discuss > *Puolesta *Cynthia Revstr?m > *L?hetetty:* maanantai 27. huhtikuuta 2020 1.03 > *Vastaanottaja:* members-discuss at ripe.net; RIPE NCC Support > > *Aihe:* [members-discuss] Regarding Elad Cohen's nomination and emails > > > > Hello, > > > > I would like to request that Elad Cohen be blocked from sending to the > members-discuss mailing lists after multiple offtopic threads started by > Elad and the personal attacks and ignoring WG chairs telling Elad to stop. > > > > I would further like to point out that as he is a confirmed candidate for > the Exec Board, one of his key responsibilities would be to have the > "Ability to communicate effectively", which he has shown that he is not > capable of. > > I would personally say that elad lacks most of the expectations listed on > https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations > . > > > > I would like to propose that the RIPE NCC ban Elad Cohen from interacting > with the RIPE Community (via Meetings or mailing lists) due to his blatant > disregard for the Code of Conduct and for being hostile towards others in > the community. As the RIPE NCC hosts and manages these lists I think the > RIPE NCC has a responsibility to keep the lists professional and to remove > those who repeatedly ignore what the WG chairs are saying. > > > > - Cynthia > > > > _______________________________________________ > > members-discuss mailing list > > members-discuss at ripe.net > > https://lists.ripe.net/mailman/listinfo/members-discuss > > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/silvan%40unavailable.online > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re > -------------- next part -------------- An HTML attachment was scrubbed... URL: From q3k at q3k.org Mon Apr 27 01:27:37 2020 From: q3k at q3k.org (Serge Bazanski) Date: Mon, 27 Apr 2020 01:27:37 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <2a4c0584-a1ef-7470-b12c-7649fca77205@marsden.space> Message-ID: I am also voicing my support for limiting Elad's interaction with this mailing list. Serge Bazanski Warsaw Hackerspace From elad at netstyle.io Mon Apr 27 01:34:46 2020 From: elad at netstyle.io (Elad Cohen) Date: Sun, 26 Apr 2020 23:34:46 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <2a4c0584-a1ef-7470-b12c-7649fca77205@marsden.space> , Message-ID: This is only because I provided a solution to replace "The Spamhaus Project". See what they are doing to me See how much they are afraid To remind - the co-chair Richard D G Cox in Ripe was part of "The Spamhaus Project" according to his presentation They have more people in Ripe, they are controlling Ripe and they are afraid of me being elected Respectfully, Elad ________________________________ From: members-discuss on behalf of Serge Bazanski Sent: Monday, April 27, 2020 2:27 AM To: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails I am also voicing my support for limiting Elad's interaction with this mailing list. Serge Bazanski Warsaw Hackerspace _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/elad%40netstyle.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From campbell at inca.ie Mon Apr 27 05:39:22 2020 From: campbell at inca.ie (Ed Campbell) Date: Mon, 27 Apr 2020 04:39:22 +0100 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: Message-ID: I support this. He has taken to emailing me directly with his conspiracy theories. Sent from my iPhone > On 26 Apr 2020, at 23:04, Cynthia Revstr?m wrote: > > ? > Hello, > > I would like to request that Elad Cohen be blocked from sending to the members-discuss mailing lists after multiple offtopic threads started by Elad and the personal attacks and ignoring WG chairs telling Elad to stop. > > I would further like to point out that as he is a confirmed candidate for the Exec Board, one of his key responsibilities would be to have the "Ability to communicate effectively", which he has shown that he is not capable of. > I would personally say that elad lacks most of the expectations listed on https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations. > > I would like to propose that the RIPE NCC ban Elad Cohen from interacting with the RIPE Community (via Meetings or mailing lists) due to his blatant disregard for the Code of Conduct and for being hostile towards others in the community. As the RIPE NCC hosts and manages these lists I think the RIPE NCC has a responsibility to keep the lists professional and to remove those who repeatedly ignore what the WG chairs are saying. > > - Cynthia > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at architekiq.ro Mon Apr 27 07:32:45 2020 From: office at architekiq.ro (Architecture Iq Data Srl) Date: Mon, 27 Apr 2020 08:32:45 +0300 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: Message-ID: <145872C1-4A12-4A72-B3C1-6EB89590676E@architekiq.ro> Hi. This is my first post to the mailing list and I only did it because you guys are flooding my mailbox. This doesn?t look like a group of professionals, its looking like my kid?s school Whatsapp group. I have to agree with Mr. Hans Govenius, I don?t know Elad or are technical enough to speak on the matter but what I know and experienced is that existing IPv6 is worse than theoretical IPv4+. It was launched several years ago with bells and whistles but was managed poorly and years later big companies ended up with 1 digit subnets while small ones had to come with justifications over justifications. IPv6 was implemented by RIPE so well that their own employees left be became brokers (isn?t that like insider trading?). We are now left with a marketplace to buy or sell IPs which is ridiculous because when you transfer an IP range it must not be in use, so how the hell can someone transfer a /16 or more ( if its not in use, means you are not using it, aren?t u supposed to give it back to RIPE?). Transfers should have only been allowed if entire LIR/company was bought, which makes more sense. So in conclusion IPv6 might be the future but it was never a solution, it?s even worse that this IPv4+. So far IPv4+ did not make IPv4 prices reach the sky, now-a-days it costs more to expand a subnet than to upgrade a router. regards ? Alex > On 27 Apr 2020, at 06:39, Ed Campbell wrote: > > I support this. He has taken to emailing me directly with his conspiracy theories. > > Sent from my iPhone > >> On 26 Apr 2020, at 23:04, Cynthia Revstr?m wrote: >> >> ? >> Hello, >> >> I would like to request that Elad Cohen be blocked from sending to the members-discuss mailing lists after multiple offtopic threads started by Elad and the personal attacks and ignoring WG chairs telling Elad to stop. >> >> I would further like to point out that as he is a confirmed candidate for the Exec Board, one of his key responsibilities would be to have the "Ability to communicate effectively", which he has shown that he is not capable of. >> I would personally say that elad lacks most of the expectations listed on https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations . >> >> I would like to propose that the RIPE NCC ban Elad Cohen from interacting with the RIPE Community (via Meetings or mailing lists) due to his blatant disregard for the Code of Conduct and for being hostile towards others in the community. As the RIPE NCC hosts and manages these lists I think the RIPE NCC has a responsibility to keep the lists professional and to remove those who repeatedly ignore what the WG chairs are saying. >> >> - Cynthia >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/office%40architekiq.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From noc at xervers.pt Mon Apr 27 08:56:12 2020 From: noc at xervers.pt (noc) Date: Mon, 27 Apr 2020 08:56:12 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <145872C1-4A12-4A72-B3C1-6EB89590676E@architekiq.ro> Message-ID: I also agree with Alex."if its not in use, means you are not using it, aren?t u supposed to give it back to RIPE".This make a lot of sense to me, because these resources (ip ranges, asn) are RIPE property.Brokers and companies are making a lot of profit selling these...Even the "selling" word is wrong. If they are "selling", the ips shouldn't become property of the buyer?? I guess it's more a loan. No?This is something I would like to hear from RIPE NCC and members.The RIPE contract is very clear to me. RIPE loans the resources and these resources can be transferred only in specific cases. If a LIR doesn't need a resource, this must be taken back to the pool...When I see the ipv4 transfer... i am disgusted! So many persons/companies wanting to "sell" ips that are in fact ripe property.?This list in my opinion, should exist yes, to sell/buy ips that are NOT RIPE property.I am sure that if RIPE take some actions on this, there will be enough IPv4 addresses for everyone till IPv6 be fully deployed.?I am sure that I will be crucified here for what I said... and I am sure that who will crucify me will be a broker or a entity that makes profit from RIPE resources.My 2ctEnviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original --------De : Architecture Iq Data Srl Data: 27/04/20 08:30 (GMT+01:00) Para: members-discuss at ripe.net Assunto: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hi. This is my first post to the mailing list and I only did it because you guys are flooding my mailbox. This doesn?t look like a group of professionals, its looking like my kid?s school Whatsapp group.I have to agree with Mr.?Hans Govenius, I don?t know Elad or are technical enough to speak ?on the matter but what I know and experienced is that existing IPv6 is worse than theoretical IPv4+. It was launched several years ago with bells and whistles but was managed poorly and years later big companies ended up with 1 digit subnets while small ones had to come with justifications over justifications. IPv6 was implemented by RIPE so well that their own employees left be became brokers (isn?t that like insider trading?). We are now left with a marketplace to buy or sell IPs which is ridiculous because ?when you transfer an IP range it must not be in use, so how the hell can someone transfer a /16 or ?more ( if its not in use, means you are not using it, aren?t u supposed to give it back to RIPE?). Transfers should have only been allowed if entire LIR/company was bought, which makes more sense. So in conclusion IPv6 might be the future but it was never a solution, it?s even worse that this IPv4+. So far IPv4+ did not make IPv4 prices reach the sky, now-a-days it costs more to expand a subnet than to upgrade a router.?regards?AlexOn 27 Apr 2020, at 06:39, Ed Campbell wrote:I support this. He has taken to emailing me directly with his conspiracy theories.?Sent from my iPhoneOn 26 Apr 2020, at 23:04, Cynthia Revstr?m wrote:?Hello,I would like to request that Elad Cohen be blocked from sending to the members-discuss mailing lists after multiple offtopic threads started by Elad and the personal attacks and ignoring WG chairs telling Elad to stop.I would further like to point out that as he is a confirmed candidate for the Exec Board, one of his key responsibilities would be to have the "Ability to communicate effectively", which he has shown that he is not capable of.I would personally say that elad lacks most of the expectations listed on?https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations.I would like to propose?that the RIPE NCC ban Elad Cohen from interacting with the RIPE Community (via Meetings or mailing lists) due to his blatant disregard for the Code of Conduct and for being hostile towards others in the community. As the RIPE NCC hosts and manages these lists I think the RIPE NCC has a responsibility to keep the lists professional and to remove those who repeatedly ignore?what the WG chairs are saying.- Cynthia _______________________________________________members-discuss mailing listmembers-discuss at ripe.nethttps://lists.ripe.net/mailman/listinfo/members-discussUnsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie_______________________________________________members-discuss mailing listmembers-discuss at ripe.nethttps://lists.ripe.net/mailman/listinfo/members-discussUnsubscribe: https://lists.ripe.net/mailman/options/members-discuss/office%40architekiq.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at v4escrow.net Mon Apr 27 09:00:03 2020 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 27 Apr 2020 00:00:03 -0700 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <145872C1-4A12-4A72-B3C1-6EB89590676E@architekiq.ro> References: <145872C1-4A12-4A72-B3C1-6EB89590676E@architekiq.ro> Message-ID: Hi Alex, although I did not want to get involved in this tread, your direct reference to me kinda makes me. On Sun, Apr 26, 2020 at 23:29 Architecture Iq Data Srl wrote: > Hi. > [...] > IPv6 was implemented by RIPE so well that their own employees left be > became brokers (isn?t that like insider trading?). > Insider trading would have been if I would have stayed employed at the RIPE NCC and opened a brokerage company as a second job. I did no such thing. I left the RIPE NCC many months before I started the IP brokerage business. Please do not imply that I did insider trading, whatever you mean by that, ever again. IPv6 had nothing to do with my decision to move on and try a new job/challenge. I am actually promoting IPv6 as much as I can. We are now left with a marketplace to buy or sell IPs which is ridiculous > because when you transfer an IP range it must not be in use, so how the > hell can someone transfer a /16 or more ( if its not in use, means you are > not using it, aren?t u supposed to give it back to RIPE?). > That is not true. We have brokered many transfers where the network using the IPs was still operational. There are many reasons why a transfer can occur, not just when IPs are not used and sold. Transfers should have only been allowed if entire LIR/company was bought, > which makes more sense. > That would have caused a nightmare to everyone. Companies reorganize, change focus, split, merge (sometimes partially). > [...] The transfer market has been in existance since 2009-2011 (depending on the region) and it has served its purpose for thousands of companies. It still serves its purpose by making IPv4 available to those in need... it comes with a cost but if you want free IPs nobody is stoping you to use IPv6 and nat/cgnat/etc. > > regards > > ? > Alex > cheers, Elvis > On 27 Apr 2020, at 06:39, Ed Campbell wrote: > > I support this. He has taken to emailing me directly with his conspiracy > theories. > > Sent from my iPhone > > On 26 Apr 2020, at 23:04, Cynthia Revstr?m wrote: > > ? > Hello, > > I would like to request that Elad Cohen be blocked from sending to the > members-discuss mailing lists after multiple offtopic threads started by > Elad and the personal attacks and ignoring WG chairs telling Elad to stop. > > I would further like to point out that as he is a confirmed candidate for > the Exec Board, one of his key responsibilities would be to have the > "Ability to communicate effectively", which he has shown that he is not > capable of. > I would personally say that elad lacks most of the expectations listed on > https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations > . > > I would like to propose that the RIPE NCC ban Elad Cohen from interacting > with the RIPE Community (via Meetings or mailing lists) due to his blatant > disregard for the Code of Conduct and for being hostile towards others in > the community. As the RIPE NCC hosts and manages these lists I think the > RIPE NCC has a responsibility to keep the lists professional and to remove > those who repeatedly ignore what the WG chairs are saying. > > - Cynthia > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/office%40architekiq.ro > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/elvis%40v4escrow.net > -- This message was sent from a mobile device. Some typos may be possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Timothy at tra.gov.om Mon Apr 27 09:14:27 2020 From: Timothy at tra.gov.om (Timothy Allen Roy) Date: Mon, 27 Apr 2020 07:14:27 +0000 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: , Message-ID: <79e89ba7ba4a4a90a54f83b7a407321a@tra.gov.om> I have never seen such bickering in a mailing list in all my life. I don't know who is wrong or right but, here is my comments with respect to it all. I do agree that this "Spamhaus" is a bit of a pain at times as I have had my business email sometimes not get delivered because of it. (and this has happened to all my businesses at one time or another) I completely disagree using this list for name calling and personal attacks on each other. There has to be a better way to resolve this bickering. With this being said I would like to suggest that for situations or allegations like that raised against things like this Spamhaus Project and or things that not only affect the Ripe community but would also have an effect for all RIR's that there be an investigative/reviewing body consisting of members from every RIR to look into these. This would require some sort of formal complaint process being set up and a set time within to respond to the plaintiff with findings. This the time frame could be from Ripe meeting to Ripe Meeting. This could also be done across all RIR's as I am quite sure that Ripe is not the only one probably having this issues. This would clear up this list for more productive conversations and resolve the non-productive bickering. Just thought I would pitch my 2 cents in there to stop this as I get enough email everyday without having to read through stuff that could be resolved through a much better process. Best Regrads Tim Roy Oman DRNO ________________________________ From: members-discuss on behalf of Ed Campbell Sent: Monday, April 27, 2020 1:50 AM To: Elad Cohen Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem So you have a solution for Google and Facebook too then? Smh. Sent from my iPhone On 26 Apr 2020, at 22:36, Elad Cohen wrote: ? According to the following link, which is a presentation that Spamhaus wrote on themselves and showed in a private event, Spamhaus is receiving high amount of illegaly-obtained privacy data of internet users from their contacts inside internet organizations and internet companies, and then (according to their presentation) they share it in illegal way without any warrant with law enforcement agencies, this is completely illegal because it is done in a systematic regular way, this is the reason that they are keeping their anonymity, this is the reason that Law Enforcement Agencies are doing nothing regarding Spamhaus (because Spamhaus is providing them on a regular basis and in a systematic methods - massive amount of illegaly-obtained intelligence data) despite all the many complaints worldwide against Spamhaus. https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The author of that private presentation as written in it is Richard D G Cox who was the co-chair of the ripe anti-abuse working group, there are more secret contacts of Spamhaus inside Ripe just like Richard D G Cox was, they are usually the ones that are trying to manipulate public opinion without any single proof, just like was done against me today. These people (Spamhaus secret contacts just like Richard D G Cox was) are bringing politics inside internet organizations, create cyber influence operations, targeting the people that they cannot control and so on. Spamhaus is an highly illegal anonymous organization and the above presentation link shows it in their own words. Respectfully, Elad ________________________________ From: Ed Campbell Sent: Monday, April 27, 2020 12:25 AM To: Elad Cohen Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Where is the proof that Spamhaus, an UK organization, are illegal or are ran by a mob? Hopefully you don?t mean that Illinois court ruling? Without a court ruling on this that is also defamation. Perhaps we can stick to what this list is for, rather than making silly accusations. Sent from my iPhone On 26 Apr 2020, at 21:58, Elad Cohen wrote: ? The spamhaus fans just cannot sit quietly in their corner. "I know you will find again great words to reply" If you wish. I'm willing to have a discussion with anyone, but a constructive discussion, not a discussion with people which have hidden interests, with people that were sent by candidates (and candidates themselves that are showing up here and yelling), not with people that their actions is due to fear. I'm not fighting everyone, on the contrary - If I will have the honor of being elected, you can be sure that I will fight for the interests of each and every one of you. I only asked the illegal anonymous organization spamhaus fans to be quiet if they want me to post my last technical solution and they know exactly who they are, I respect everyone else and I respect Ripe. Regarding the "leadership qualities" that you are referring to, I definitely not have the "leadership qualities" of our Chairman as was written about him here: https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html But there is only one problem with it, when our board member Maria pasted to the textarea the text that our Chairman wrote on himself and sent to her - she forgot to remove the title from it, so this is what we see in the above link: "Reason for nominating the candidate: Reason for nominating the candidate: " the second same title is because a copy-paste was done here, our Chairman, 15 minutes after he nominated Maria with a single sentence - sent a whole paragraph on himself to Maria for her to use it when she nominated him, this is what our Chairman wrote on himself: (among other things in the whole paragraph in the link above) "Christian has shown very strong and positive leadership in his role as chair of the board" If that is what our Chairman and our Board member are doing behind the scenes (Maria cheated the community that these are her words while she didn't even read it, she did only copy-paste), we cannot trust them with managing Ripe expenses and the fact is that thy are denying to reveal detailed financial information and they are denying detailed transparency. so I lack that kind of "leadership qualities" , I do have other leadership qualities - I stood up against "The Spamhaus Project - something that only few dare to do, I'm taking the heat from you each and every day but still it doesn't impact me a bit, yesterday here I stood up against a group of IPv6 deployers that have an interest that IPv4+ will not be implemented - but we all truly know (just like the very vast majority of the internet community) that it is the right thing to do, I stood up against them all, alone. Regarding your last paragraph: "All I can see is a guy, who tries to get elected because he really desperately needs something in his CV, and because the chances might be thin (you haven't even bothered to bring any CV or something up, while at least 3 candidates actually put in the effort so we can judge what they have done in the past. You share nothing of your past, what you have done, where you have participated. instead you try to push your campaign by pushing your own ideas on an unsuitable platform." I will not answer that paragraph because of the way that it is written, you just displayed yourself in it at the darkest distorted light. Where did you see that I'm trying to be elected ? did you see me jumping into other discussion lists and start yelling on candidates ? (like was done here) - do you want me to write about myself like our Chairman did ? I believe in taking the right actions, not in creating the right connections. This is not a campaign - this is me showing my ideas to the community before they will be implemented. I don't believe in living in the past and I personally dislike any kind of bragging. Don't you care about what a candidate will do if and after it will be chosen ? this I didn't hear from anyone. People only know how to talk about themselves. No worries, you will know exactly what are my plans for Ripe and you can be sure that if I will be elected I will take Ripe to its golden age - and each and every LIR member will enjoy from it, until the last one. Silvan, you are obviously supporting another candidate, you shouldn't fear from me, I come with open hands and with a clean heart. Respectfully, Elad ________________________________ From: members-discuss on behalf of Silvan Gebhardt Sent: Sunday, April 26, 2020 10:31 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Hi Elad, it's me again, one of your favourite illegals. You are a candidate for the Board of RIPE. as a RIPE board member you should be able to actually have a discussion with people, to engage in disputes in a constructive way, instead you instantly pick a fight, and try to fight everyone who does not agree with your points. You ask that Members here - which are most likely other members of LIRS which have as much a right to state their opinion, "stay quiet" - or you suggest to remove them from the mailinglist. This clearly does not look good for you, Elad - leave the accusations away, you are definitely not displaying any leadership qualities which would be required as board of RIPE. So, accusations against you, you ask for proof. You yourself state accusations against RIPE Board ("corruption") but you do not provide any proof. All I can see is a guy, who tries to get elected because he really desperately needs something in his CV, and because the chances might be thin (you haven't even bothered to bring any CV or something up, while at least 3 candidates actually put in the effort so we can judge what they have done in the past. You share nothing of your past, what you have done, where you have participated. instead you try to push your campaign by pushing your own ideas on an unsuitable platform. I agree that "even bad publicity can be some publicity" - but it will not help you on your election because at this rate, the only vote you get is your own word. I know you will find again great words to reply, it will greatly amuse me. trust me, if you start picking fights with everyone, people will start digging and open up a case with the arbiter under clause 1.2.1.1 section 2 On 4/26/20 7:15 PM, Elad Cohen wrote: If the Spamhaus fans will be quiet in their corner then tomorrow will be the last technical solution. Respectfully, Elad ________________________________ From: Darren Brown Sent: Sunday, April 26, 2020 10:13 PM To: Elad Cohen ; href ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad it?s great you have so many ideas but this is getting a bit silly now, go and take a break , have a drink and put in a film. It?s Sunday evening , chill out Regards Darren Get Outlook for iOS ________________________________ From: members-discuss on behalf of Elad Cohen Sent: Sunday, April 26, 2020 8:09:09 PM To: href ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem "I had no idea that you may have been involved in the Cape Town hijack!" The cyber influence operation continue... complete lies without a single proof, can anyone show a single proof ? Are you so scared from me being elected ? that you need to spread lies ? I'm highly honored that the illegal anonymous organization "The Spamhaus Project" decided to attack me, it means a lot. Lets see who is the Spamhaus fan that will jump now. Respectfully, Elad ________________________________ From: href Sent: Sunday, April 26, 2020 10:01 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad, Some members sent some additional information about you: I can now understand your replies: I had no idea that you may have been involved in the Cape Town hijack! Please forget about my badly chosen example. Accusations aside, it is time to get serious and I'll re-iterate my original question: what are your thoughts and technical solutions about IP hijacking (not the Cape town one) ? On 4/26/20 8:23 PM, Elad Cohen wrote: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. ---- Can you show a single proof to what you are writing? You are taking part in an illegal cyber influence operation against me. Respectfully, Elad ________________________________ From: Jordan Bracco Sent: Sunday, April 26, 2020 9:14 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Elad, I do not see what you mean by "telling a lie again and again". I have a vague memory of something fishy going on with a Cape Town ip block, but there was many occurences like this. I cited Cape Town as an example. I do not have proof, so maybe the Cape Town is a false memory, but IP hijacking (which was the subject of my email, not Cape Town) surely do happen. For the rest of your reply-- I just simply do not understand it. - I fail to see a correlation between hijacking IP space and Spamhaus. Could you please enlighten me ? - I also fail to understand what you mean by "mob friends just like you". I have no relationship whatsoever with SpamHaus, I do not use their DNSBLs (as I delegate most of my emails to Fastmail). I was just asking for your thoughts and technical solutions to IP space hijacking. Your reply turned into a rant about Spamhaus (?) and accusing me of being "mob friend" of it (?) ? On Sun, Apr 26, 2020, at 19:46, Elad Cohen wrote: Jordan, What you are writing is false, telling a lie again and again will not make it truth. "if I remember that there was some IP space from Cape Town city that got hijacked" - I'll be happy if you can also remember a single proof for it and to display it here now ? (I mean a proof - not an employee of of a direct competitor which is also a member of the illegal anonymous organization "The Spamhaus Project" and also the owner of that illegal anonymous twitter account: https://twitter.com/underthebreach - he is also a cyber influence master according to himself - it means that he is a master in telling lies and creating a fake story without a single proof in order to influence public opinion - exactly like what you are doing now) And yes, I did found a technical solution for your criminals at "The Spamhaus Project" that there are many complaints about them worldwide - and the Law Enforcement Agencies are doing nothing regarding them only because they illegaly share (without any warrant) on a regular basis and in a systematic way massive amount of illegaly-obtained privacy data of internet users with the Law Enforcement Agencies as you can see that they wrote on themselves in their own words in the following link: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation "The Spamhaus Project" mob friends just like you are very very afraid from me according to their attention to me - and they are afraid from me because I cannot be bought, because what they are doing is illegal, because I will keep saying it loudly again and again and again. Respectfully, Elad ________________________________ From: members-discuss on behalf of Jordan Bracco Sent: Sunday, April 26, 2020 8:23 PM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical Solution to resolve the global "Email Spam" problem Dear Elad, Unrelated to the spam proposal-- but have you found a technical solution to avoid malicious third parties to hijack assigned IP space (for example, if I remember that there was some IP space from Cape Town city that got hijacked). What are you thoughts on this, and your technical solution to it ? On Sun, Apr 26, 2020, at 18:05, Elad Cohen wrote: Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/href%40fastmail.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/silvan%40unavailable.online _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie From aleksi at magnacapax.fi Mon Apr 27 11:55:54 2020 From: aleksi at magnacapax.fi (Aleksi) Date: Mon, 27 Apr 2020 12:55:54 +0300 Subject: [members-discuss] Technical Solution to resolve the global "Email Spam" problem In-Reply-To: References: <1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net> Message-ID: Hi, ?You clearly misunderstand what "centralized" is. Your local government is a good example of a centralized service with multiple points of service. Single organization, where decisions for all of the multiple service points is made from same place. UPS and DHL too, they are single organizations with many many service points all over the world. Certainly their service is decentralized physically and has to be by nature, but they are single organization and decisions made by single body concerning all of those service points. Only a few executives making all the decisions. That is a centralized service. A mailing list does not concern most of the world population. No amount of sugar coating will make your proposal anything but draconian and potentially orwellian. Besides, there are easier ways to solve the spam problem -- using blockchain you can, spamassassin plugins etc. you can make e-mail system in a way where sending email costs just enough to make spamming not as financially viable. (Have made proposals to blockchain groups in the past, bottomline is we would need to develop our own proof of concept to gain any traction) -Aleksi On 4/26/20 9:28 PM, Elad Cohen wrote: > It is not centralized because there are many servers with bgp anycast > spread all over the world. > > All the data in NoSpam.org backend infrastructure is hashed. > > All the data which is sent between an email client to NoSpam.org > backend infrastructure is hashed. > > Queries that the email client send to NoSpam.org backend are not > logged and are not saved in any way. > > Currently - when you register to an online mailing list or to a > newsletter - it is also centralized - and in cleartext (not hashed), > so this is exactly the same - just much bigger infrastructure? spread > over many locations in the world with bgp anycast. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* members-discuss on behalf > of Aleksi > *Sent:* Sunday, April 26, 2020 9:04 PM > *To:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] Technical Solution to resolve the > global "Email Spam" problem > > a centralized solution ... Yikes! > > Next step permits for email, only to be approved by government > officials? For spam review purposes all emails must be stored > centrally? Certainly no abuse will ever happen. > > > > On 4/26/20 7:50 PM, Matthias Brumm wrote: >> >> Hi! >> >> >> To understand correctly. You want to enforce, that every subscribe >> operation / e-mail client operation (get new email from server) in >> the world will make a bidirectional communication with a central >> server? Do you have an ellaborated guess, how much computing power >> that would need? >> >> >> Matthias >> >> >> Am 26.04.20 um 18:05 schrieb Elad Cohen: >>> Hello Everyone, >>> >>> I want to share with you my technical solution to resolve the global >>> world "Email Spam" problem and in addition it will also resolve the >>> spreading of illegal links (phishing/malware/etc , once the sites >>> are known) through electronic mail and will stop email spoofing >>> (that part using current technologies). >>> >>> Email spam problem was not being able to be defeated since the >>> beginning of electronic mail, as long as email spam will be >>> profitable to email spammers - it will exist, email spam caused the >>> illegal anonymous organization "The Spamhaus Project" to exist, "The >>> Spamhaus Project" is hurting and damaging many businesses worldwide >>> in their way to fight email spam, "The Spamhaus Project" is an >>> illegal anonymous organization according to the following >>> presentation that they wrote on themselves, they are violating laws >>> in their way to fight email spam and still they don't win in the >>> battle against email spam. "The Spamhaus Project" is keeping their >>> anonymity because they are afriad of justified lawsuits due to their >>> criminal actions in their way to fight email spam. The following >>> technical solution will resolve the world email spam problem without >>> to hurt and to damage many businesses worldwide that have nothing to >>> do with email spam like "The Spamhaus Project" does, the following >>> implementation can remove the need for an illegal anonymous >>> organization such as "The Spamhaus Project". >>> >>> >>> The presentation that the illegal anonymous organization "The >>> Spamhaus Project" wrote on themselves: >>> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation >>> >>> >>> >>> The Implementation: >>> >>> There will be a site (lets call it NoSpam.org) - the site will be >>> owned by the 5 RIRs, the site will use bgp anycast and will be >>> deployed in each of the 5 RIRs (the site will also be able to be >>> deployed by the ccTLD registries in each country), the site in all >>> the locations will be synced automatically. >>> >>> Each domain owner will be able to register at the site (an email >>> message will be sent to the domain owner email address in the domain >>> name WHOIS details in order to verify that the domain owner is the >>> one registering). >>> >>> After being logged in, a domain owner will be able to add his email >>> addresses (of the specific domain name) that will be used to send >>> newsletters / mailing lists / one-to-many email messages, lets call >>> these kind of email addresses as 'mailing list' email addresses. The >>> domain owner will not be able to see the list of 'mailing list' >>> email addresses that he added - because when he added each 'mailing >>> list' email address it will be saved with hash in the NoSpam.org >>> backend infrastructure (due to privacy and security reasons) - hence >>> only if the domain owner will manually type the 'mailing list' email >>> address he will be able to enter it in order to manage it (to see >>> the total number of subscribers email addresses, to see the >>> subscribers email addresses but only with their hashes due to >>> security and privacy reasons, to remove a subscriber from the list, >>> to add a sub-user with permissions to manage that specific 'mailing >>> list' email address). >>> >>> In his site, the domain owner will be able to integrate an iframe >>> from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a >>> subscriber registration form to his specific 'mailing list' email >>> address, the subscriber will receive an email message with a link to >>> confirm his subscription. >>> >>> The domain owner will need to create a callback file in his website, >>> for example in the path: "/nospam-notification-callback" >>> (http://example.com/nospam-notification-callback) - that url will >>> receive encrypted post notifications (encryption key will be >>> provided by the domain owner in his NoSpam.org logged in account) >>> from NoSpam.org regarding any new end-user that will subscribe or >>> that will unsubscribe from a 'mailing address' email address which >>> is related to the domain of the domain owner (unsubscribe >>> functionality by the user later below). >>> >>> The subscriber email address and that 'mailing list' email address >>> (that was subscribed to) will be sent by NoSpam.org to >>> "/nospam-notification-callback" not in the hashed format but in >>> cleartext (so the domain owner will be able to save it in his system >>> for future email messages from the specific 'mailing list' email >>> address to the specific subscriber email address). >>> >>> The domain owner will also have an API to NoSpam.org backend >>> infrastructure in order to remove a specific subscriber email >>> address from a specific 'mailing list' email address (the domains >>> owner will send the values through the API - hashed). >>> >>> The domain owner will also provide a web interface in his site for >>> the end-user to remove himself from the specific 'mailing list' >>> email address. >>> >>> >>> >>> The above is the backend implementation (no upgrade is needed to any >>> email server in the internet), the following is the upgrade that >>> will needed for any email client (that upgrade is not mandatory, >>> without the following upgrade the email client will work exactly as >>> it is now without the added no-spam features, electronic mail will >>> not break if some email users will upgrade their email clients and >>> some will not): >>> >>> - There will not be 'mark as spam' button, that kind of >>> functionality will stop to exist because spam is not a boolean >>> value, 'spam' to one person is valuable to another 'person', >>> specially when the internet is global and different people from >>> different countries will consider spam content differently. One user >>> can consider an email message as spam and another user can consider >>> the same message as not spam, 'Spam' is subjective and any kind of >>> 'mark as spam' functionality is useless in the battle against email >>> spam. >>> >>> - There will be blacklists and whitelists (just like there are now, >>> but they will be more prominent): blacklist email addresses , >>> blacklist domains , whitelist email addresses , whitelist domains. >>> >>> - The end-user should be able to easily enter each email message to >>> whitelist or to blacklist (meaning the 'from' email address of the >>> email message), and will be able to search in the 'Spam' folder >>> easily for an email address (these features can exist today, but >>> they should be given more visibility, so end-users will use them more). >>> >>> - The end-user will be able to import/export his whitelists and >>> blacklists using an xml format to any other upgraded email client, >>> the blacklists and whitelists will be local (end-user will be able >>> to pass the local whitelists and blacklists to another email client >>> of his with the click of a button in the upgraded email client - the >>> upgraded email client will just send them to itself - without to >>> download them from the email server so the end-user will be able to >>> download it with another upgraded email client - or the end-user >>> will be able to send the whitelists and blacklists to another email >>> address of him, the usage will not be like sending regular email >>> message with attachments - the upgraded email clients will take care >>> to sending and receiving of the blacklists and whitelits - in the >>> background, these are custom formatted email messages that the two >>> upgraded email clients will know how to act upon them). >>> >>> - The email client will be able to display with GUI with buttons any >>> 'mailing-list registration confirmation email' in a specific section >>> related to registration to new 'mailing list' email addresses for >>> the end-user to choose with buttons if he accept or refuse to >>> register to a specific 'mailing list' email address. >>> >>> - For any email message that was received: in case a received 'from' >>> email address was found in the whitelist email addresses or in the >>> whitelist domains - then it will be moved to the 'Inbox' folder, in >>> case the 'from' email address of the email message was found in the >>> blacklist email addresses or in the blacklist domains - then the >>> email message will be moved to the 'Trash' folder. >>> >>> - In case the 'from' email address or domain was not found in the >>> whitelists and in the blacklists, then the upgraded email client >>> will send the 'from' email address and the 'from' domain and the >>> current user email address and the external links that exist in the >>> email message (but all of these data will be sent in a hashed way, >>> and not in cleartext) with a query to NoSpam.org backend >>> infrastructure, NoSpam.org will perform the following algorithem >>> after it: >>> >>> - If the hashed 'from' domain (or any other 'hashed' domain from the >>> external links) exist in a list of criminals hashed domains (of >>> phishing/malware/viruses/etc) then NoSpam.org will respond to the >>> email client to delete the email message, otherwise the hashed >>> 'from' email address will be checked against a list of hashed >>> 'mailing list' email addresses - if found then the sender is a >>> 'mailing list' email address and there will be a check by NoSpam.org >>> backend infrastructure if the hashed 'receiver' email address is a >>> subscriber of that specific 'mailing list' email address , if the >>> hashed 'receiver' was found then NoSpam.org will send a response to >>> the email client that the email message can be displayed in the >>> 'Inbox' folder and in the response NoSpam.org will also include an >>> unsubscribe key - the email client will be able to display an >>> unsubscribe button to the email client and if clicked the email >>> client will send an https request to NoSpam.org with the specific >>> unsubscribe key, NoSpam.org backend infrastructure will remove the >>> end-user email address from the 'mailing list' email address and >>> will notify the domain owner at the domain owner callback url >>> "/nospam-notification-callback" that the specific user unsubscribed. >>> In case the hashed 'receiver' wasn't found then NoSpam.org will >>> respond to the email client to delete the email message and >>> NoSpam.org will also notify the callback url of the related domain >>> owner that he shouldn't send email messages from the specific >>> 'mailing ?list' email address to the specific subscriber email address. >>> >>> - In case when NoSpam.org backend infrastructure searched the hashed >>> 'from' email address and it wasn't found in the list of all hashed >>> 'mailing list' email addresses, it mean that the email address was >>> sent from a 'personal' email address and NoSpam.org backend >>> infrastructure will notify the email client that the email message >>> is from a 'personal' email address - the email client in that stage >>> will need to decide if to move the email message to the 'Inbox' >>> folder or to the 'Spam' folder based on the following - the email >>> client will check if the email message include >>> links/images/plain-url's - and if yes then the email message will be >>> moved to the 'Spam' folder, otherwise it will be moved to the >>> 'Inbox' folder. >>> >>> >>> >>> >>> Whitelist Handshake: >>> >>> - In order to facilitate the adding of new email address to the >>> local whitelist, a process of 'Whitelist Handshake' exist , a >>> 'Whitelist Handshake' is a GUI representation in two email clients >>> regarding background email messages between them (that the two >>> end-users don't see), "end-user A" with a click of a button will be >>> able to send 'add me to whitelist' request to "end-user B" which >>> will be able to accept or deny and if accepted then "end-user B" >>> will be able to automatically send the same "add me to whitelist" >>> request to "end-user A" , all of this communication will be done >>> behind the scenes, these special email messages will not be visible >>> to the end-users, end-users will see popups with GUI that email >>> address X is asking to be added to whitelist. In order for spammers >>> not to abuse this option - the email client will keep only one >>> 'whitelist request' from each requester email address (there will be >>> a 'whitelist requests' section in the upgraded email client). A >>> repeated 'whitelist request' that came from a specific email address >>> can never be raised in the list (unless the end-user will >>> specifically search for it) even when the sender will send more and >>> more 'add me to whitelist' requests - no priority will given to >>> them, and once an end-user refused an 'add me to whitelist' request >>> - no new 'add me to whitelist' request will be shown from the >>> specific sender email address in the specific email client. >>> >>> - There can be a case that an upgraded email client will send 'add >>> me to whitelist' request to a not-upgraded email client and then the >>> receiver will see the request as it is - as an email message in the >>> inbox folder - due to it the content of that message will be in the >>> language of the domain TLD of the receiver email address and the >>> content in the email message will explain what is NoSpam.org and how >>> to upgrade the email client and supported upgraded email clients, etc >>> >>> - In the 'whitelist requests section' in the upgraded email client - >>> the whitelist requests will appear in a list - there should be >>> preference so some requests will appear upper and other lower (so >>> requests from spammers will appear lower) - whitelist requests from >>> email addresses of domains which are older (according to their WHOIS >>> details) will appear upper than whitelist requests from email >>> addresses of domains which are newer. Whitelist requests from a list >>> of a more-trusted-domains (domains of known webmails service, >>> universities, governments, etc) will have preference over other >>> domains, specific TLDs that not anyone can purchase will also have >>> preference over other TLDs that anyone can purchase (upgraded email >>> clients will retrieve the list of trusted TLD's and Domains each day >>> from NoSpam.org backend infrastructure). >>> >>> >>> Notification of spam emails: >>> >>> - An additional feature in the upgraded email client is that >>> whenever an email message will reach the 'Spam' folder - the email >>> client will send in the background a known-format email message to >>> the sender and will notify him about it, if the sender is using an >>> upgraded email client then it will be able to automatically send a >>> 'add me to whitelist' request to the receiver in the background >>> (once an email address is whitelisted - all the email messages from >>> it will move from 'Spam' to 'Inbox'). >>> >>> >>> >>> Email Spoofing: >>> >>> - In an upgraded email client, email messages from 'personal' email >>> addresses cannot arrive from email relay server, in case it happen >>> the message will be deleted and the email client will send an >>> automatic email message in the background to the sender with the >>> text (in the language of the sender domain TLD) that email messages >>> from 'email relay servers' cannot be received from him. >>> >>> - In an upgraded email client, email messages from 'mailing list' >>> email addresses can arrive from email relay servers - but they must >>> be encrypted with DKIM. >>> >>> - In an upgraded email client, the email client should check the SPF >>> txt dns record of the sender domain, and will drop the email message >>> if it is a spoofed email message. >>> >>> - DNS servers developers will need to make the SPF txt dns record to >>> be a mandatory field for every domain, in order for email spoofing >>> to be annihilated. >>> >>> >>> >>> Security Aspects: >>> >>> - All stored data in NoSpam.org Backend infrastructure is hashed. >>> >>> - The criminals domains list in NoSpam.org Backend Infrastructure >>> will be managed only by regulated supervised Law Enforcement Agency >>> (for example: Interpol) and not by an internet organization such as >>> the RIRs or ccTLD registries. >>> >>> - Domains owners will have 'forgot password' functionality to their >>> NoSpam.org account, the password reset link will be sent to the >>> email address of the owner of the domain according to the domain >>> WHOIS details. >>> >>> - Communication between email clients to NoSpam.org backend >>> infrastructure will be over https, there will only be an handshake >>> process in the beginning over electronic mail between email client >>> and NoSpam.org backend infrastructure - the email client will send >>> an email message with a chosen key to an email address of >>> @nospam.org (that key will be used in further communication between >>> the email client and the NoSpam.org backend infrastructure over >>> https, it will be used for NoSpam.org backend infrastructure to >>> identify the specific email address over https, so anyone will not >>> be able to query NoSpam.org backend infrastructure to know which >>> hashed email address belongs to which hashed 'mailing list' email >>> address, besides the email client user with the right key to query >>> NoSpam.org Backend infrastructure only on himself). >>> >>> - Any email client will download once per day 'spam-rules' file from >>> NoSpam.org backend infrastructure, 'spam-rules' file will be an xml >>> formatted file that include rules of when to move an email message >>> that was received from 'personal' email address which is not >>> whitelisted to the 'Spam' folder (for example, when email have at >>> least 1/2/3 links, when email format is rich text or html and not >>> plaintext, etc), in case future adjustments will be needed to win >>> the battle against email spam - email clients will not need to be >>> upgraded, the new 'spam-rules' will be updated in this daily file. >>> >>> >>> To make it short: >>> >>> - Any email message from a subscribed mailing list / newsletter / >>> etc - will reach to the inbox (that kind of email messages can >>> contain any kind of content without any restrictions, because the >>> user subscribed to it and the user can unsubscribe from it at anytime). >>> >>> - Any email message from an email address or domain in whitelist - >>> will reach the inbox. >>> >>> - Whitelist Handshake process is easy to use and being implemented >>> with clicks of a button, nothing to type. >>> >>> - In case an email message will the 'Spam' folder - an automatic >>> email message will be sent from the receiver to sender and sender >>> can automatically ask to be added to the receiver's whitelist. >>> >>> - Any email message without links/images/plain-url's (plain email >>> messages, like electronic email was) - will reach the inbox. >>> >>> - Any other email will reach the 'Spam' folder - if needed the user >>> will be able to easily whitelist the email message in the 'Spam' folder. >>> >>> >>> >>> Spammers need links in their email messages for monetization, above >>> solution blocks it and also block criminal domains links in email >>> message and implement email spoofing blocking at client-side. We >>> will all stop to receive more than 100 spam email messages per day >>> with the above solution. >>> >>> >>> Respectfully, >>> Elad >>> >>> >>> _______________________________________________ >>> members-discuss mailing list >>> members-discuss at ripe.net >>> https://lists.ripe.net/mailman/listinfo/members-discuss >>> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net >> -- >> Unser Familien-Blog:https://brumm.family >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi -------------- next part -------------- An HTML attachment was scrubbed... URL: From hlk at kramse.org Mon Apr 27 12:25:07 2020 From: hlk at kramse.org (hlk) Date: Mon, 27 Apr 2020 12:25:07 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: Message-ID: Hello all, and sorry for top posting mobile device.The amount of noise generated by Elad Cohen and unwillingness to listen has degraded the lists. Polite rejections of his proposals have quickly degenerated into name calling and conspiracy theories by him.I am not affiliated with RIPE NCC other than being a LIR, I do not know Elad Cohen before these threads. Quick searches on his name show dubious business practices, as seen with regards to prefix hijacking.I consider his actions on the list very close to overstepping Code of Conduct, and good intentions. I fully support both him being moderated on the list, and not being eligble for a position as RIPE chair or similar for the moment.Best regardsHenrik Kramselund Jereminsen, owner of dk.zencurity -------- Original message --------From: Filip Hruska Date: 4/27/20 01:05 (GMT+01:00) To: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hello all, I would like to voice my support for this. The amount of unprofessional conduct in the past 2 or 3 email chains is simply ridiculous and completely unacceptable. Thank you, Filip On 4/27/20 12:44 AM, Joseph Marsden wrote: I support Cynthia's request for a formal investigation. Best Joseph On 26/04/2020 23:24, Cynthia Revstr?m wrote: I would also like to formally request that the RIPE NCC investigate if Elad Cohen has breached A.1.2.2.B of RIPE-716. https://www.ripe.net/publications/docs/ripe-716#a122b This is with regards to statements like this: "Ripe have 30 millions euros of expenses each year that are hidden and now shown to where exactly they are paid, instead of that corruption" I believe that he does indeed make unreasonable allegations towards the RIPE NCC to damage it's reputation. - Cynthia On Mon, Apr 27, 2020 at 12:02 AM Cynthia Revstr?m wrote: Hello, I would like to request that Elad Cohen be blocked from sending to the members-discuss mailing lists after multiple offtopic threads started by Elad and the personal attacks and ignoring WG chairs telling Elad to stop. I would further like to point out that as he is a confirmed candidate for the Exec Board, one of his key responsibilities would be to have the "Ability to communicate effectively", which he has shown that he is not capable of. I would personally say that elad lacks most of the expectations listed on?https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations. I would like to propose?that the RIPE NCC ban Elad Cohen from interacting with the RIPE Community (via Meetings or mailing lists) due to his blatant disregard for the Code of Conduct and for being hostile towards others in the community. As the RIPE NCC hosts and manages these lists I think the RIPE NCC has a responsibility to keep the lists professional and to remove those who repeatedly ignore?what the WG chairs are saying. - Cynthia _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/joseph%40arctarus.co.uk _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/fhr%40fhrnet.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Mon Apr 27 12:39:46 2020 From: elad at netstyle.io (Elad Cohen) Date: Mon, 27 Apr 2020 10:39:46 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: , Message-ID: Hello, Is it possible for anyone with hidden intentions not to post on this list ? Henrik, you could just write "I don't vote for Elad" - no need to try to spread lies to the community - can you provide a single proof to the lies that you wrote about me ? as I already wrote - the "source" in the fake media report is a person in "The Spamhaus Project" and an employee of a direct business competitor and also the owner of that criminal twitter account: https://twitter.com/underthebreach The "source" of the fake media report as you can see in his "anonymous" twitter account linked above - is a master of cyber influence operations - and this is exactly what being done here - spreading of lies and conspiracies and fake theories about me without a single proof. I didn't share any conspiracies, I only provided a link to a presentation of "The Spamhaus Project" that they wrote on themselves and they presented in a private event - According to their own words they are an illegal anonymous organization. "The Spamhaus Project" is related to the cyber-security community mainly in Western countries - so indeed Henrik is from the cyber-security community, expect more wannabe "security researchers" to write lies about me. "The Spamhaus Project" keeps attacking me because they know that if I will be elected I will make sure that they will not hurt anymore any Ripe LIR member. Respectfully, Elad ________________________________ From: members-discuss on behalf of hlk via members-discuss Sent: Monday, April 27, 2020 1:25 PM To: Filip Hruska ; members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hello all, and sorry for top posting mobile device. The amount of noise generated by Elad Cohen and unwillingness to listen has degraded the lists. Polite rejections of his proposals have quickly degenerated into name calling and conspiracy theories by him. I am not affiliated with RIPE NCC other than being a LIR, I do not know Elad Cohen before these threads. Quick searches on his name show dubious business practices, as seen with regards to prefix hijacking. I consider his actions on the list very close to overstepping Code of Conduct, and good intentions. I fully support both him being moderated on the list, and not being eligble for a position as RIPE chair or similar for the moment. Best regards Henrik Kramselund Jereminsen, owner of dk.zencurity -------- Original message -------- From: Filip Hruska Date: 4/27/20 01:05 (GMT+01:00) To: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hello all, I would like to voice my support for this. The amount of unprofessional conduct in the past 2 or 3 email chains is simply ridiculous and completely unacceptable. Thank you, Filip On 4/27/20 12:44 AM, Joseph Marsden wrote: I support Cynthia's request for a formal investigation. Best Joseph On 26/04/2020 23:24, Cynthia Revstr?m wrote: I would also like to formally request that the RIPE NCC investigate if Elad Cohen has breached A.1.2.2.B of RIPE-716. https://www.ripe.net/publications/docs/ripe-716#a122b This is with regards to statements like this: "Ripe have 30 millions euros of expenses each year that are hidden and now shown to where exactly they are paid, instead of that corruption" I believe that he does indeed make unreasonable allegations towards the RIPE NCC to damage it's reputation. - Cynthia On Mon, Apr 27, 2020 at 12:02 AM Cynthia Revstr?m > wrote: Hello, I would like to request that Elad Cohen be blocked from sending to the members-discuss mailing lists after multiple offtopic threads started by Elad and the personal attacks and ignoring WG chairs telling Elad to stop. I would further like to point out that as he is a confirmed candidate for the Exec Board, one of his key responsibilities would be to have the "Ability to communicate effectively", which he has shown that he is not capable of. I would personally say that elad lacks most of the expectations listed on https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-functions-and-expectations. I would like to propose that the RIPE NCC ban Elad Cohen from interacting with the RIPE Community (via Meetings or mailing lists) due to his blatant disregard for the Code of Conduct and for being hostile towards others in the community. As the RIPE NCC hosts and manages these lists I think the RIPE NCC has a responsibility to keep the lists professional and to remove those who repeatedly ignore what the WG chairs are saying. - Cynthia _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/joseph%40arctarus.co.uk _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/fhr%40fhrnet.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-md at c4inet.net Mon Apr 27 12:40:32 2020 From: ripe-md at c4inet.net (Sascha Luck [ml]) Date: Mon, 27 Apr 2020 11:40:32 +0100 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: Message-ID: <20200427104032.GU2680@cilantro.c4inet.net> On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net From me at cynthia.re Mon Apr 27 12:50:30 2020 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Mon, 27 Apr 2020 12:50:30 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <20200427104032.GU2680@cilantro.c4inet.net> References: <20200427104032.GU2680@cilantro.c4inet.net> Message-ID: > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] wrote: > On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: > >I would like to propose that the RIPE NCC ban Elad Cohen from interacting > >with the RIPE Community (via Meetings or mailing lists) due to his blatant > >disregard for the Code of Conduct and for being hostile towards others in > >the community. As the RIPE NCC hosts and manages these lists I think the > >RIPE NCC has a responsibility to keep the lists professional and to remove > >those who repeatedly ignore what the WG chairs are saying. > > The RIPE *NCC* has no business either enforcing "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. Nor do I think the NCC should determine who can > be a member of the RIPE community or not. If I'm wrong, where do > I submit the list of people I'd like to see excluded from the > community? > I think this proposal is the most out-of-order thing I've yet > seen in this thread. > > rgds, > Sascha Luck > > > > >- Cynthia > > >_______________________________________________ > >members-discuss mailing list > >members-discuss at ripe.net > >https://lists.ripe.net/mailman/listinfo/members-discuss > >Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Mon Apr 27 12:58:48 2020 From: elad at netstyle.io (Elad Cohen) Date: Mon, 27 Apr 2020 10:58:48 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net>, Message-ID: Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss on behalf of Cynthia Revstr?m Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at cynthia.re Mon Apr 27 13:05:28 2020 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Mon, 27 Apr 2020 13:05:28 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net> Message-ID: Elad, first of all, I am not an employee or in any way related to Spamhaus, and I doubt many of the people you have suggested are part of it have anything to do with it either. And because I have things to do that are not spending my entire days on RIPE mailing lists I guess I missed RFG calling you names, but I will assure you that if I was on those discussions I would call him out if he called you a "coconut" or similar. Also just because someone has called you names on mailing lists doesn't mean you get to call them names on mailing lists. - Cynthia On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen wrote: > Cynthia, > > The sick person which you are referring to and is your colleague from "The > Spamhaus Project", defamed me for many many months, here in Ripe and in > Nanog, he called me by many names without a single proof. He was called an > antisemitic and a racist not by me - but by people which are not related > to me in Nanog. After many months I provided an official response in Ripe. > I didn't hear your voice when he defamed me for many many months with him > calling me by many names. So obviously your interests are hidden. > > In the other working groups - I only replied to him, and I didn't hear > your voice regarding your sick colleague initial message with name callings > towards me when I only replied to his attack on me. And his personal attack > on me is exactly like your personal attack on me now - you are afraid that > an alternative solution to "The Spamhaus Project" will be implemented if I > will be elected. > > Respectfully, > Elad > ------------------------------ > *From:* members-discuss on behalf of > Cynthia Revstr?m > *Sent:* Monday, April 27, 2020 1:50 PM > *To:* Sascha Luck [ml] > *Cc:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and > emails > > > The RIPE *NCC* has no business either enforcing "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. > > AFAIK there are no WG chairs of members-discuss and members-discuss is a > mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE > NCC membership related topics, so I think they certainly have business > enforcing people to be professional on this mailing list. > > I would also like to add that Elad has multiple times on different mailing > lists ignored the WG chairs. > Also this is happening across a variety of RIPE/RIPE NCC mailing lists > that are all hosted by the RIPE NCC and as such I think it is their > business to keep them to a professional standard. > > > If I'm wrong, where do > I submit the list of people I'd like to see excluded from the > community? > > There should not be a long list of people, but when someone is behaving > unprofessionally, calling people "coconut", being defamatory towards the > RIPE NCC, ignoring WG chairs, I do think that they have gone too far and > everything has a limit. > Like we wouldn't allow someone to send sales emails to the mailing list as > an example, aka limits on what is allowed. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: > > On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: > >I would like to propose that the RIPE NCC ban Elad Cohen from interacting > >with the RIPE Community (via Meetings or mailing lists) due to his blatant > >disregard for the Code of Conduct and for being hostile towards others in > >the community. As the RIPE NCC hosts and manages these lists I think the > >RIPE NCC has a responsibility to keep the lists professional and to remove > >those who repeatedly ignore what the WG chairs are saying. > > The RIPE *NCC* has no business either enforcing "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. Nor do I think the NCC should determine who can > be a member of the RIPE community or not. If I'm wrong, where do > I submit the list of people I'd like to see excluded from the > community? > I think this proposal is the most out-of-order thing I've yet > seen in this thread. > > rgds, > Sascha Luck > > > > >- Cynthia > > >_______________________________________________ > >members-discuss mailing list > >members-discuss at ripe.net > >https://lists.ripe.net/mailman/listinfo/members-discuss > >Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dk at hostmaster.ua Mon Apr 27 13:10:30 2020 From: dk at hostmaster.ua (Dmitry Kohmanyuk) Date: Mon, 27 Apr 2020 14:10:30 +0300 Subject: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world In-Reply-To: References: <20200426104228.GL90387@carcass.ledeuns.net> Message-ID: <541B48AA-461C-4FFD-B4E5-F536AE5E74D9@hostmaster.ua> On Apr 26, 2020, at 16:45, Elad Cohen wrote: > > Someone tried to do it to me as well. > > Respectfully, > Elad Have you seen that South Park episode where Dildo Schwaggins and his team destroy the Danish system called Troll Trace? Perhaps something like that can be built. We already know IP address.. How hard can it be? > > From: members-discuss on behalf of Ed Campbell > Sent: Sunday, April 26, 2020 4:43 PM > To: members-discuss at ripe.net > I?m not sure what is going on here but someone tried to remove me from this list?. > > You know who you are ... > > Mailing list removal confirmation notice for mailing list > members-discuss > > We have received a request from 188.26.42.62 for the removal of your > email address, [...] This one belongs to residential ISP in Romania. inetnum: 188.26.32.0 - 188.26.63.255 netname: RO-RESIDENTIAL descr: RCS & RDS Residential descr: City: Bucuresti country: RO admin-c: RDS-RIPE tech-c: RDS-RIPE tech-c: RDS2012-RIPE status: ASSIGNED PA mnt-by: AS8708-MNT mnt-lower: AS8708-MNT created: 2012-11-09T16:12:17Z last-modified: 2013-10-03T10:47:29Z source: RIPE # Filtered role: RCS & RDS NOC address: 71-75 Dr. Staicovici address: Bucharest / ROMANIA phone: +40 21 30 10 888 fax-no: +40 21 30 10 892 abuse-mailbox: abuse at rcs-rds.ro admin-c: GEPU1-RIPE tech-c: GEPU1-RIPE nic-hdl: RDS-RIPE mnt-by: RDS-MNT remarks: ? dk@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Mon Apr 27 13:12:04 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Mon, 27 Apr 2020 11:12:04 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net>, Message-ID: <3b4a8cd8a59c4dfea59e78ec9f4d1fae@safehosts.co.uk> Elad, I had not hear of you before the posts you made about IPv4+ and spam. I have seen that you are very quick to accuse anyone who disagrees with you of some form of conspiracy. Rather than jump to conclusions, I did a quick google search for your name and company. Wow. I think your best move now would be to quietly slip into the background before too many people start investigating AFRINIC IP addresses.... Best regards, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: Monday, 27 April 2020 11:59 To: Cynthia Revstr?m ; Sascha Luck [ml] Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Mon Apr 27 13:12:29 2020 From: elad at netstyle.io (Elad Cohen) Date: Mon, 27 Apr 2020 11:12:29 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net> , Message-ID: He called me with antisemitic names many times and on many working groups and you said nothing, you claim not to see his messages, but you clearly saw all of my messages and you are monitoring me pretty well. I'm sorry but I don't believe you, specially when you are attacking me personally so heavily with distorting the facts. You clearly so the word coconut - so you also saw what I shared on the same post that he wrote on other groups of people and that he was called a racist and an antisemitic - but you decided to ignore this as well, so you didn't read my whole post - you read only the word 'coconut' and you decided to jump in ? Cynthia, please spread your lies somewhere else. Respectfully, Elad ________________________________ From: Cynthia Revstr?m Sent: Monday, April 27, 2020 2:05 PM To: Elad Cohen Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, first of all, I am not an employee or in any way related to Spamhaus, and I doubt many of the people you have suggested are part of it have anything to do with it either. And because I have things to do that are not spending my entire days on RIPE mailing lists I guess I missed RFG calling you names, but I will assure you that if I was on those discussions I would call him out if he called you a "coconut" or similar. Also just because someone has called you names on mailing lists doesn't mean you get to call them names on mailing lists. - Cynthia On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen > wrote: Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-md at c4inet.net Mon Apr 27 13:14:21 2020 From: ripe-md at c4inet.net (Sascha Luck [ml]) Date: Mon, 27 Apr 2020 12:14:21 +0100 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net> Message-ID: <20200427111421.GW2680@cilantro.c4inet.net> On Mon, Apr 27, 2020 at 12:50:30PM +0200, Cynthia Revstrm wrote: >AFAIK there are no WG chairs of members-discuss and members-discuss is a >mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE >NCC membership related topics, so I think they certainly have business >enforcing people to be professional on this mailing list. see my reply to Geert above, I didn't get into *this* list as it is indeed managed by the NCC. > >I would also like to add that Elad has multiple times on different mailing >lists ignored the WG chairs. Then the WG chairs already have the power to moderate list subscribers and have (rarely) done so in the past. >Also this is happening across a variety of RIPE/RIPE NCC mailing lists that >are all hosted by the RIPE NCC and as such I think it is their business to >keep them to a professional standard. Maybe the wg lists should then be hosted elsewhere. It's not generally considered acceptable for a hoster to moderate mailing lists it hosts for a "customer". >There should not be a long list of people, but when someone is behaving >unprofessionally, calling people "coconut", being defamatory towards the >RIPE NCC, ignoring WG chairs, I do think that they have gone too far and >everything has a limit. >Like we wouldn't allow someone to send sales emails to the mailing list as >an example, aka limits on what is allowed. Either case is for the WG chairs do decide, *not* the NCC which is only the hoster for those lists. members-discuss is of course different as it is "owned" by the NCC. rgds, Sascha Luck From me at cynthia.re Mon Apr 27 13:14:24 2020 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Mon, 27 Apr 2020 13:14:24 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net> Message-ID: Elad, please send me an archive link to the specific email on a RIPE/RIPE NCC mailing list where RFG called you a rude name. - Cynthia On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen wrote: > He called me with antisemitic names many times and on many working groups > and you said nothing, you claim not to see his messages, but you clearly > saw all of my messages and you are monitoring me pretty well. I'm sorry but > I don't believe you, specially when you are attacking me personally so > heavily with distorting the facts. You clearly so the word coconut - so you > also saw what I shared on the same post that he wrote on other groups of > people and that he was called a racist and an antisemitic - but you decided > to ignore this as well, so you didn't read my whole post - you read only > the word 'coconut' and you decided to jump in ? > > Cynthia, please spread your lies somewhere else. > > Respectfully, > Elad > ------------------------------ > *From:* Cynthia Revstr?m > *Sent:* Monday, April 27, 2020 2:05 PM > *To:* Elad Cohen > *Cc:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and > emails > > Elad, first of all, I am not an employee or in any way related to > Spamhaus, and I doubt many of the people you have suggested are part of it > have anything to do with it either. > > And because I have things to do that are not spending my entire days on > RIPE mailing lists I guess I missed RFG calling you names, but I will > assure you that if I was on those discussions I would call him out if he > called you a "coconut" or similar. > Also just because someone has called you names on mailing lists doesn't > mean you get to call them names on mailing lists. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen wrote: > > Cynthia, > > The sick person which you are referring to and is your colleague from "The > Spamhaus Project", defamed me for many many months, here in Ripe and in > Nanog, he called me by many names without a single proof. He was called an > antisemitic and a racist not by me - but by people which are not related > to me in Nanog. After many months I provided an official response in Ripe. > I didn't hear your voice when he defamed me for many many months with him > calling me by many names. So obviously your interests are hidden. > > In the other working groups - I only replied to him, and I didn't hear > your voice regarding your sick colleague initial message with name callings > towards me when I only replied to his attack on me. And his personal attack > on me is exactly like your personal attack on me now - you are afraid that > an alternative solution to "The Spamhaus Project" will be implemented if I > will be elected. > > Respectfully, > Elad > ------------------------------ > *From:* members-discuss on behalf of > Cynthia Revstr?m > *Sent:* Monday, April 27, 2020 1:50 PM > *To:* Sascha Luck [ml] > *Cc:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and > emails > > > The RIPE *NCC* has no business either enforcing "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. > > AFAIK there are no WG chairs of members-discuss and members-discuss is a > mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE > NCC membership related topics, so I think they certainly have business > enforcing people to be professional on this mailing list. > > I would also like to add that Elad has multiple times on different mailing > lists ignored the WG chairs. > Also this is happening across a variety of RIPE/RIPE NCC mailing lists > that are all hosted by the RIPE NCC and as such I think it is their > business to keep them to a professional standard. > > > If I'm wrong, where do > I submit the list of people I'd like to see excluded from the > community? > > There should not be a long list of people, but when someone is behaving > unprofessionally, calling people "coconut", being defamatory towards the > RIPE NCC, ignoring WG chairs, I do think that they have gone too far and > everything has a limit. > Like we wouldn't allow someone to send sales emails to the mailing list as > an example, aka limits on what is allowed. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: > > On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: > >I would like to propose that the RIPE NCC ban Elad Cohen from interacting > >with the RIPE Community (via Meetings or mailing lists) due to his blatant > >disregard for the Code of Conduct and for being hostile towards others in > >the community. As the RIPE NCC hosts and manages these lists I think the > >RIPE NCC has a responsibility to keep the lists professional and to remove > >those who repeatedly ignore what the WG chairs are saying. > > The RIPE *NCC* has no business either enforcing "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. Nor do I think the NCC should determine who can > be a member of the RIPE community or not. If I'm wrong, where do > I submit the list of people I'd like to see excluded from the > community? > I think this proposal is the most out-of-order thing I've yet > seen in this thread. > > rgds, > Sascha Luck > > > > >- Cynthia > > >_______________________________________________ > >members-discuss mailing list > >members-discuss at ripe.net > >https://lists.ripe.net/mailman/listinfo/members-discuss > >Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.simmons at elite.net.uk Mon Apr 27 13:19:16 2020 From: david.simmons at elite.net.uk (David Simmons) Date: Mon, 27 Apr 2020 11:19:16 +0000 Subject: [members-discuss] UNSUBSCRIBE Message-ID: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> UNSUBSCRIBE -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Mon Apr 27 13:23:35 2020 From: elad at netstyle.io (Elad Cohen) Date: Mon, 27 Apr 2020 11:23:35 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <3b4a8cd8a59c4dfea59e78ec9f4d1fae@safehosts.co.uk> References: <20200427104032.GU2680@cilantro.c4inet.net>, , <3b4a8cd8a59c4dfea59e78ec9f4d1fae@safehosts.co.uk> Message-ID: Stuart, The cyber influence operation of "The Spamhaus Project" against me proceed... I didn't accuse anyone with anything. The simple facts are: * That IPv6 deployers have an interest that IPv4+ will not be deployed. * That "The Spamhaus Project" have more people in Ripe just like they had Richard D G Cox, the past co-chair of the Ripe Anti-Abuse Working Group. Regarding the fake media reports that were originated from "The Spamhaus Project" - the "source" of the fake media reports is a member of "The Spamhaus Project" and an employee of a direct business competitor that used the netblock and wanted to hurt their business competitor and also the owner of the criminal twitter account: https://twitter.com/underthebreach and a master of cyber influence operations according to his own words in his criminal twitter account (meaning to create a fake story without a single proof), there is no a single proof in any of the fake media reports and there will never be. Stuart, you can be sure that whenever I will see "The Spamhaus Project" doing injustice - I will stand up - even if more 100000000 fake media reports without a single proof will be written against me, "The Spamhaus Project" is an illegal anonymous organization - only because this organization is providing a massive amount of illegaly obtained privacy data that was extorted from internet companies such as hosting companies - and then providing it in illegal way (without any warrant) to law enforcement agencies - and by that helping the law enforcement agencies to do their work - the law enforcement agencies are ignoring all the complaints from many businesses worldwide regarding the criminal operation of "The Spamhaus Project". Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Monday, April 27, 2020 2:12 PM To: Elad Cohen ; Cynthia Revstr?m ; Sascha Luck [ml] Cc: members-discuss at ripe.net Subject: RE: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, I had not hear of you before the posts you made about IPv4+ and spam. I have seen that you are very quick to accuse anyone who disagrees with you of some form of conspiracy. Rather than jump to conclusions, I did a quick google search for your name and company. Wow. I think your best move now would be to quietly slip into the background before too many people start investigating AFRINIC IP addresses?. Best regards, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: Monday, 27 April 2020 11:59 To: Cynthia Revstr?m ; Sascha Luck [ml] Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re -------------- next part -------------- An HTML attachment was scrubbed... URL: From viethen at itc.rwth-aachen.de Mon Apr 27 13:26:45 2020 From: viethen at itc.rwth-aachen.de (Viethen, Christoph) Date: Mon, 27 Apr 2020 11:26:45 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net>, , Message-ID: <2a7e6225692c4395bf2ea57872c75b92@itc.rwth-aachen.de> People, could you please discuss those personal matters among yourselves? (And whoever provided Internet access to that sandbox in kindergarten ... please give them back their sand castles and their little buckets and shovels and all and let them play games appropriate to their age. Thank you.) C. From santos at tvcehegin.com Mon Apr 27 13:32:43 2020 From: santos at tvcehegin.com (Santos Martinez Guirao) Date: Mon, 27 Apr 2020 13:32:43 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net> Message-ID: <137d31e5-b0bd-1bad-8ba7-a9c016a8e123@tvcehegin.com> UNISUSCRIBE LIST El 27/4/20 a las 13:14, Cynthia Revstr?m escribi?: > Elad, please send me an archive link to the specific email on a > RIPE/RIPE NCC mailing list where RFG called you a rude name. > > - Cynthia > > On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen > wrote: > > He called me with antisemitic names many times and on many working > groups and you said nothing, you claim not to see his messages, > but you clearly saw all of my messages and you are monitoring me > pretty well. I'm sorry but I don't believe you, specially when you > are attacking me personally so heavily with distorting the facts. > You clearly so the word coconut - so you also saw what I shared on > the same post that he wrote on other groups of people and that he > was called a racist and an antisemitic - but you decided to ignore > this as well, so you didn't read my whole post - you read only the > word 'coconut' and you decided to jump in ? > > Cynthia, please spread your lies somewhere else. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* Cynthia Revstr?m > > *Sent:* Monday, April 27, 2020 2:05 PM > *To:* Elad Cohen > > *Cc:* members-discuss at ripe.net > > > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination > and emails > Elad, first of all, I am not an employee or in any way related to > Spamhaus, and I doubt many of the people you have suggested are > part of it have anything to do with it either. > > And because I have things to do that are not spending my entire > days on RIPE mailing lists I guess I missed RFG calling you names, > but I will assure you that if I was on those discussions I would > call him out if he called you a "coconut" or similar. > Also just because someone has called you names on mailing lists > doesn't mean you get to call them names on mailing lists. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen > wrote: > > Cynthia, > > The sick person which you are referring to and is your > colleague from "The Spamhaus Project", defamed me for many > many months, here in Ripe and in Nanog, he called me by many > names without a single proof. He was called an antisemitic and > a? racist not by me - but by people which are not related to > me in Nanog. After many months I provided an official response > in Ripe. I didn't hear your voice when he defamed me for many > many months with him calling me by many names. So obviously > your interests are hidden. > > In the other working groups - I only replied to him, and I > didn't hear your voice regarding your sick colleague initial > message with name callings towards me when I only replied to > his attack on me. And his personal attack on me is exactly > like your personal attack on me now - you are afraid that an > alternative solution to "The Spamhaus Project" will be > implemented if I will be elected. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* members-discuss > on behalf of > Cynthia Revstr?m > > *Sent:* Monday, April 27, 2020 1:50 PM > *To:* Sascha Luck [ml] > > *Cc:* members-discuss at ripe.net > > > *Subject:* Re: [members-discuss] Regarding Elad Cohen's > nomination and emails > > The RIPE *NCC* has no business either enforcing > "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. > > AFAIK there are no WG chairs of members-discuss and > members-discuss is a mailing list that the RIPE NCC hosts to > let RIPE NCC members discuss RIPE NCC membership related > topics, so I think they certainly have business enforcing > people to be professional on this mailing list. > > I would also like to add that Elad has multiple times on > different mailing lists ignored the WG chairs. > Also this is happening across a variety of RIPE/RIPE NCC > mailing lists that are all hosted by the RIPE NCC and as such > I think it is their business to keep them to a professional > standard. > > > If I'm wrong, where do > I submit the list of people I'd like to see excluded from the > community? > > There should not be a long list of people, but when someone is > behaving unprofessionally, calling people "coconut", being > defamatory towards the RIPE NCC, ignoring WG chairs, I do > think that they have gone too far and everything has a limit. > Like we wouldn't allow someone to send sales emails to the > mailing list as an example, aka limits on what is allowed. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > > wrote: > > On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm > wrote: > >I would like to propose that the RIPE NCC ban Elad Cohen > from interacting > >with the RIPE Community (via Meetings or mailing lists) > due to his blatant > >disregard for the Code of Conduct and for being hostile > towards others in > >the community. As the RIPE NCC hosts and manages these > lists I think the > >RIPE NCC has a responsibility to keep the lists > professional and to remove > >those who repeatedly ignore what the WG chairs are saying. > > The RIPE *NCC* has no business either enforcing > "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. Nor do I think the NCC should determine > who can > be a member of the RIPE community or not. If I'm wrong, > where do > I submit the list of people I'd like to see excluded from the > community? > I think this proposal is the most out-of-order thing I've yet > seen in this thread. > > rgds, > Sascha Luck > > > > >- Cynthia > > >_______________________________________________ > >members-discuss mailing list > >members-discuss at ripe.net > >https://lists.ripe.net/mailman/listinfo/members-discuss > >Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/santos%40tvcehegin.com -- Santos Martinez Guirao Tlf +34 696815396 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at velder.li Mon Apr 27 13:35:31 2020 From: lists at velder.li (Patrick Velder) Date: Mon, 27 Apr 2020 13:35:31 +0200 Subject: [members-discuss] UNSUBSCRIBE In-Reply-To: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> References: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> Message-ID: Please. Not. Again. :-( Is it really that difficult. There's an unsubscribe link in every e-mail you get from this list. On 27.04.20 13:19, David Simmons wrote: > > UNSUBSCRIBE > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/lists%40velder.li -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.schaepers at vsqloud.de Mon Apr 27 13:48:54 2020 From: m.schaepers at vsqloud.de (=?utf-8?B?TWF1cmljaW8gU2Now6RwZXJz?=) Date: Mon, 27 Apr 2020 11:48:54 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <2a7e6225692c4395bf2ea57872c75b92@itc.rwth-aachen.de> References: <20200427104032.GU2680@cilantro.c4inet.net>, , <2a7e6225692c4395bf2ea57872c75b92@itc.rwth-aachen.de> Message-ID: <2e5baca1c3314063bb9d37eff209349e@vsqloud.de> Agreed. I like to be a member on this list and there have been very interesting discussions. But this here has become a very personal and emotional discussion, not to say a mud fight. Please take a breath and calm down a bit. This conversation is currently just leading people to unsubscribe from the list -----Original Message----- From: members-discuss On Behalf Of Viethen, Christoph Sent: Monday, 27 April 2020 13:27 To: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails People, could you please discuss those personal matters among yourselves? (And whoever provided Internet access to that sandbox in kindergarten ... please give them back their sand castles and their little buckets and shovels and all and let them play games appropriate to their age. Thank you.) C. _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/m.schaepers%40vsqloud.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3631 bytes Desc: not available URL: From me at cynthia.re Mon Apr 27 13:50:14 2020 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Mon, 27 Apr 2020 13:50:14 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net> Message-ID: Hi Elad, There are 3 major differences I see here, 1. rfg presents lots of evidence that you would have been involved in shady things (I am not sure if they are true and frankly I don't have time currently to look at all of the documents) Meanwhile you are saying that people are part of "The illegal anonymous Spamhaus Project" just because they disagree with you, and as you have said that I am involved in Spamhaus, I would like for you to give me any proof that I am involved with spamhaus in any way (which I am not). 2. rfg called you a "crook", which means dishonest or illegal, which would be true if the things rfg stated are in fact true. Meanwhile you called rfg a "coconut" which can't be anything other than an insult referring to you thinking he is dumb. 3. rfg called you a "crook" once in a long email after describing why he thinks you are a "crook", meanwhile you sent an email that I have posted in its entirety below. > START Michael, Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. Respectfully, Elad > END Please just stop it Elad. Now I still think it was wrong of rfg to use that word, but it is not at all the same thing in my eyes. - Cynthia On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen wrote: > > https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301.html > > These are all complete lies only because I found out who are the real > people behind "The Spamhaus Project" > > You can see how he is calling me there > > Everything there are lies and fake, the "source" for the fake media report > is a member of "The Spamhaus Project" and also an employee of a direct > competitor (that enjoyed from that fake media report) of a company which > used the netblock, and the "source" is also the owner of that criminal > twitter account: https://twitter.com/UnderTheBreach , he is a master of > cyber influence operations according to his own words in his criminal > twitter account and also a member of your cyber-security community. > > Respectfully, > Elad > ------------------------------ > *From:* Cynthia Revstr?m > *Sent:* Monday, April 27, 2020 2:14 PM > *To:* Elad Cohen > *Cc:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and > emails > > Elad, please send me an archive link to the specific email on a RIPE/RIPE > NCC mailing list where RFG called you a rude name. > > - Cynthia > > On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen wrote: > > He called me with antisemitic names many times and on many working groups > and you said nothing, you claim not to see his messages, but you clearly > saw all of my messages and you are monitoring me pretty well. I'm sorry but > I don't believe you, specially when you are attacking me personally so > heavily with distorting the facts. You clearly so the word coconut - so you > also saw what I shared on the same post that he wrote on other groups of > people and that he was called a racist and an antisemitic - but you decided > to ignore this as well, so you didn't read my whole post - you read only > the word 'coconut' and you decided to jump in ? > > Cynthia, please spread your lies somewhere else. > > Respectfully, > Elad > ------------------------------ > *From:* Cynthia Revstr?m > *Sent:* Monday, April 27, 2020 2:05 PM > *To:* Elad Cohen > *Cc:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and > emails > > Elad, first of all, I am not an employee or in any way related to > Spamhaus, and I doubt many of the people you have suggested are part of it > have anything to do with it either. > > And because I have things to do that are not spending my entire days on > RIPE mailing lists I guess I missed RFG calling you names, but I will > assure you that if I was on those discussions I would call him out if he > called you a "coconut" or similar. > Also just because someone has called you names on mailing lists doesn't > mean you get to call them names on mailing lists. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen wrote: > > Cynthia, > > The sick person which you are referring to and is your colleague from "The > Spamhaus Project", defamed me for many many months, here in Ripe and in > Nanog, he called me by many names without a single proof. He was called an > antisemitic and a racist not by me - but by people which are not related > to me in Nanog. After many months I provided an official response in Ripe. > I didn't hear your voice when he defamed me for many many months with him > calling me by many names. So obviously your interests are hidden. > > In the other working groups - I only replied to him, and I didn't hear > your voice regarding your sick colleague initial message with name callings > towards me when I only replied to his attack on me. And his personal attack > on me is exactly like your personal attack on me now - you are afraid that > an alternative solution to "The Spamhaus Project" will be implemented if I > will be elected. > > Respectfully, > Elad > ------------------------------ > *From:* members-discuss on behalf of > Cynthia Revstr?m > *Sent:* Monday, April 27, 2020 1:50 PM > *To:* Sascha Luck [ml] > *Cc:* members-discuss at ripe.net > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and > emails > > > The RIPE *NCC* has no business either enforcing "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. > > AFAIK there are no WG chairs of members-discuss and members-discuss is a > mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE > NCC membership related topics, so I think they certainly have business > enforcing people to be professional on this mailing list. > > I would also like to add that Elad has multiple times on different mailing > lists ignored the WG chairs. > Also this is happening across a variety of RIPE/RIPE NCC mailing lists > that are all hosted by the RIPE NCC and as such I think it is their > business to keep them to a professional standard. > > > If I'm wrong, where do > I submit the list of people I'd like to see excluded from the > community? > > There should not be a long list of people, but when someone is behaving > unprofessionally, calling people "coconut", being defamatory towards the > RIPE NCC, ignoring WG chairs, I do think that they have gone too far and > everything has a limit. > Like we wouldn't allow someone to send sales emails to the mailing list as > an example, aka limits on what is allowed. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: > > On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: > >I would like to propose that the RIPE NCC ban Elad Cohen from interacting > >with the RIPE Community (via Meetings or mailing lists) due to his blatant > >disregard for the Code of Conduct and for being hostile towards others in > >the community. As the RIPE NCC hosts and manages these lists I think the > >RIPE NCC has a responsibility to keep the lists professional and to remove > >those who repeatedly ignore what the WG chairs are saying. > > The RIPE *NCC* has no business either enforcing "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. Nor do I think the NCC should determine who can > be a member of the RIPE community or not. If I'm wrong, where do > I submit the list of people I'd like to see excluded from the > community? > I think this proposal is the most out-of-order thing I've yet > seen in this thread. > > rgds, > Sascha Luck > > > > >- Cynthia > > >_______________________________________________ > >members-discuss mailing list > >members-discuss at ripe.net > >https://lists.ripe.net/mailman/listinfo/members-discuss > >Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.morreale at tradingnetwork.it Mon Apr 27 14:01:50 2020 From: a.morreale at tradingnetwork.it (TNC - Alessandro Morreale) Date: Mon, 27 Apr 2020 14:01:50 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net> Message-ID: <2d3783da-27ae-32b6-8dec-d4e4e1f5481d@tradingnetwork.it> Is there any good guy that can exclude me from this conversation? It seems the unsubscribe link I used several times doesn't work and, to be honest over 170 messages from this group in last two days it's really too much thanks fof your comprehension Il 27/04/20 13:50, Cynthia Revstr?m ha scritto: > Hi Elad, > > There are 3 major differences I see here, > > 1. rfg presents lots of evidence that you would have been involved in > shady things (I am not sure if they are true and frankly I don't have > time currently to look at all of the documents) > Meanwhile you are saying that people are part of "The illegal > anonymous Spamhaus Project" just because they disagree with you, and > as you have said that I am involved in Spamhaus, I would like for you > to give me any proof that I am involved with spamhaus in any way > (which I am not). > > 2. rfg called you a "crook", which means dishonest or illegal, which > would be true if the things rfg stated are in fact true. Meanwhile you > called rfg a "coconut" which can't be anything other than an insult > referring to you thinking he is dumb. > > 3. rfg called you a "crook" once in a long email after describing why > he thinks you are a "crook", meanwhile you sent an email that I have > posted in its entirety below. > > > START > Michael, > > Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. > > Respectfully, > Elad > > END > > Please just stop it Elad. > > Now I still think it was wrong of rfg to use that word, but it is not > at all the same thing in my eyes. > > - Cynthia > > On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen > wrote: > > https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301.html > > These are all complete lies only because I found out who are the > real people behind "The Spamhaus Project" > > You can see how he is calling me there > > Everything there are lies and fake, the "source" for the fake > media report is a member of "The Spamhaus Project" and also an > employee of a direct competitor (that enjoyed from that fake media > report) of a company which used the netblock, and the "source" is > also the owner of that criminal twitter account: > https://twitter.com/UnderTheBreach > , he is a master of cyber > influence operations according to his own words in his criminal > twitter account and also a member of your cyber-security community. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* Cynthia Revstr?m > > *Sent:* Monday, April 27, 2020 2:14 PM > *To:* Elad Cohen > > *Cc:* members-discuss at ripe.net > > > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination > and emails > Elad, please send me an archive link to the specific email on a > RIPE/RIPE NCC mailing list where RFG called you a rude name. > > - Cynthia > > On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen > wrote: > > He called me with antisemitic names many times and on many > working groups and you said nothing, you claim not to see his > messages, but you clearly saw all of my messages and you are > monitoring me pretty well. I'm sorry but I don't believe you, > specially when you are attacking me personally so heavily with > distorting the facts. You clearly so the word coconut - so you > also saw what I shared on the same post that he wrote on other > groups of people and that he was called a racist and an > antisemitic - but you decided to ignore this as well, so you > didn't read my whole post - you read only the word 'coconut' > and you decided to jump in ? > > Cynthia, please spread your lies somewhere else. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* Cynthia Revstr?m > > *Sent:* Monday, April 27, 2020 2:05 PM > *To:* Elad Cohen > > *Cc:* members-discuss at ripe.net > > > *Subject:* Re: [members-discuss] Regarding Elad Cohen's > nomination and emails > Elad, first of all, I am not an employee or in any way related > to Spamhaus, and I doubt many of the people you have suggested > are part of it have anything to do with it either. > > And because I have things to do that are not spending my > entire days on RIPE mailing lists I guess I missed RFG calling > you names, but I will assure you that if I was on those > discussions I would call him out if he called you a "coconut" > or similar. > Also just because someone has called you names on mailing > lists doesn't mean you get to call them names on mailing lists. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen > wrote: > > Cynthia, > > The sick person which you are referring to and is your > colleague from "The Spamhaus Project", defamed me for many > many months, here in Ripe and in Nanog, he called me by > many names without a single proof. He was called an > antisemitic and a? racist not by me - but by people which > are not related to me in Nanog. After many months I > provided an official response in Ripe. I didn't hear your > voice when he defamed me for many many months with him > calling me by many names. So obviously your interests are > hidden. > > In the other working groups - I only replied to him, and I > didn't hear your voice regarding your sick colleague > initial message with name callings towards me when I only > replied to his attack on me. And his personal attack on me > is exactly like your personal attack on me now - you are > afraid that an alternative solution to "The Spamhaus > Project" will be implemented if I will be elected. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* members-discuss > on behalf of > Cynthia Revstr?m > > *Sent:* Monday, April 27, 2020 1:50 PM > *To:* Sascha Luck [ml] > > *Cc:* members-discuss at ripe.net > > > > *Subject:* Re: [members-discuss] Regarding Elad Cohen's > nomination and emails > > The RIPE *NCC* has no business either enforcing > "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. > > AFAIK there are no WG chairs of members-discuss and > members-discuss is a mailing list that the RIPE NCC hosts > to let RIPE NCC members discuss RIPE NCC membership > related topics, so I think they certainly have business > enforcing people to be professional on this mailing list. > > I would also like to add that Elad has multiple times on > different mailing lists ignored the WG chairs. > Also this is happening across a variety of RIPE/RIPE NCC > mailing lists that are all hosted by the RIPE NCC and as > such I think it is their business to keep them to a > professional standard. > > > If I'm wrong, where do > I submit the list of people I'd like to see excluded from the > community? > > There should not be a long list of people, but when > someone is behaving unprofessionally, calling people > "coconut", being defamatory towards the RIPE NCC, ignoring > WG chairs, I do think that they have gone too far and > everything has a limit. > Like we wouldn't allow someone to send sales emails to the > mailing list as an example, aka limits on what is allowed. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > > wrote: > > On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia > Revstrm wrote: > >I would like to propose that the RIPE NCC ban Elad > Cohen from interacting > >with the RIPE Community (via Meetings or mailing > lists) due to his blatant > >disregard for the Code of Conduct and for being > hostile towards others in > >the community. As the RIPE NCC hosts and manages > these lists I think the > >RIPE NCC has a responsibility to keep the lists > professional and to remove > >those who repeatedly ignore what the WG chairs are > saying. > > The RIPE *NCC* has no business either enforcing > "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. Nor do I think the NCC should > determine who can > be a member of the RIPE community or not. If I'm > wrong, where do > I submit the list of people I'd like to see excluded > from the > community? > I think this proposal is the most out-of-order thing > I've yet > seen in this thread. > > rgds, > Sascha Luck > > > > >- Cynthia > > >_______________________________________________ > >members-discuss mailing list > >members-discuss at ripe.net > > >https://lists.ripe.net/mailman/listinfo/members-discuss > >Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/a.morreale%40tradingnetwork.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From munir at aeserver.com Mon Apr 27 14:07:35 2020 From: munir at aeserver.com (Munir Badr) Date: Mon, 27 Apr 2020 16:07:35 +0400 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <2d3783da-27ae-32b6-8dec-d4e4e1f5481d@tradingnetwork.it> References: <20200427104032.GU2680@cilantro.c4inet.net> <2d3783da-27ae-32b6-8dec-d4e4e1f5481d@tradingnetwork.it> Message-ID: Wow guys there is some intense action going on here. It seems that the best way to END this is to *STOP replying and reacting*. Go do something else on the quarantine. For those who are still arguing, get a room and do it there, you dont need to spam everyone on the list. I dont care about anything you write here and this is my first and last reply to this thread. On Mon, Apr 27, 2020 at 4:02 PM TNC - Alessandro Morreale < a.morreale at tradingnetwork.it> wrote: > Is there any good guy that can exclude me from this conversation? > > It seems the unsubscribe link I used several times doesn't work and, to be > honest over 170 messages from this group in last two days it's really too > much > > thanks fof your comprehension > Il 27/04/20 13:50, Cynthia Revstr?m ha scritto: > > Hi Elad, > > There are 3 major differences I see here, > > 1. rfg presents lots of evidence that you would have been involved in > shady things (I am not sure if they are true and frankly I don't have time > currently to look at all of the documents) > Meanwhile you are saying that people are part of "The illegal anonymous > Spamhaus Project" just because they disagree with you, and as you have said > that I am involved in Spamhaus, I would like for you to give me any proof > that I am involved with spamhaus in any way (which I am not). > > 2. rfg called you a "crook", which means dishonest or illegal, which would > be true if the things rfg stated are in fact true. Meanwhile you called rfg > a "coconut" which can't be anything other than an insult referring to you > thinking he is dumb. > > 3. rfg called you a "crook" once in a long email after describing why he > thinks you are a "crook", meanwhile you sent an email that I have posted in > its entirety below. > > > START > > Michael, > > Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. > > Respectfully, > Elad > > > END > > Please just stop it Elad. > > Now I still think it was wrong of rfg to use that word, but it is not at > all the same thing in my eyes. > > - Cynthia > > On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen wrote: > >> >> https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301.html >> >> These are all complete lies only because I found out who are the real >> people behind "The Spamhaus Project" >> >> You can see how he is calling me there >> >> Everything there are lies and fake, the "source" for the fake media >> report is a member of "The Spamhaus Project" and also an employee of a >> direct competitor (that enjoyed from that fake media report) of a company >> which used the netblock, and the "source" is also the owner of that >> criminal twitter account: https://twitter.com/UnderTheBreach , he is a >> master of cyber influence operations according to his own words in his >> criminal twitter account and also a member of your cyber-security community. >> >> Respectfully, >> Elad >> ------------------------------ >> *From:* Cynthia Revstr?m >> *Sent:* Monday, April 27, 2020 2:14 PM >> *To:* Elad Cohen >> *Cc:* members-discuss at ripe.net >> *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and >> emails >> >> Elad, please send me an archive link to the specific email on a RIPE/RIPE >> NCC mailing list where RFG called you a rude name. >> >> - Cynthia >> >> On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen wrote: >> >> He called me with antisemitic names many times and on many working groups >> and you said nothing, you claim not to see his messages, but you clearly >> saw all of my messages and you are monitoring me pretty well. I'm sorry but >> I don't believe you, specially when you are attacking me personally so >> heavily with distorting the facts. You clearly so the word coconut - so you >> also saw what I shared on the same post that he wrote on other groups of >> people and that he was called a racist and an antisemitic - but you decided >> to ignore this as well, so you didn't read my whole post - you read only >> the word 'coconut' and you decided to jump in ? >> >> Cynthia, please spread your lies somewhere else. >> >> Respectfully, >> Elad >> ------------------------------ >> *From:* Cynthia Revstr?m >> *Sent:* Monday, April 27, 2020 2:05 PM >> *To:* Elad Cohen >> *Cc:* members-discuss at ripe.net >> *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and >> emails >> >> Elad, first of all, I am not an employee or in any way related to >> Spamhaus, and I doubt many of the people you have suggested are part of it >> have anything to do with it either. >> >> And because I have things to do that are not spending my entire days on >> RIPE mailing lists I guess I missed RFG calling you names, but I will >> assure you that if I was on those discussions I would call him out if he >> called you a "coconut" or similar. >> Also just because someone has called you names on mailing lists doesn't >> mean you get to call them names on mailing lists. >> >> - Cynthia >> >> On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen wrote: >> >> Cynthia, >> >> The sick person which you are referring to and is your colleague from >> "The Spamhaus Project", defamed me for many many months, here in Ripe and >> in Nanog, he called me by many names without a single proof. He was called >> an antisemitic and a racist not by me - but by people which are not >> related to me in Nanog. After many months I provided an official response >> in Ripe. I didn't hear your voice when he defamed me for many many months >> with him calling me by many names. So obviously your interests are hidden. >> >> In the other working groups - I only replied to him, and I didn't hear >> your voice regarding your sick colleague initial message with name callings >> towards me when I only replied to his attack on me. And his personal attack >> on me is exactly like your personal attack on me now - you are afraid that >> an alternative solution to "The Spamhaus Project" will be implemented if I >> will be elected. >> >> Respectfully, >> Elad >> ------------------------------ >> *From:* members-discuss on behalf of >> Cynthia Revstr?m >> *Sent:* Monday, April 27, 2020 1:50 PM >> *To:* Sascha Luck [ml] >> *Cc:* members-discuss at ripe.net >> *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and >> emails >> >> > The RIPE *NCC* has no business either enforcing "professionality" >> on the *community* mailing lists - this is the WG chairs' >> responsibility. >> >> AFAIK there are no WG chairs of members-discuss and members-discuss is a >> mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE >> NCC membership related topics, so I think they certainly have business >> enforcing people to be professional on this mailing list. >> >> I would also like to add that Elad has multiple times on different >> mailing lists ignored the WG chairs. >> Also this is happening across a variety of RIPE/RIPE NCC mailing lists >> that are all hosted by the RIPE NCC and as such I think it is their >> business to keep them to a professional standard. >> >> > If I'm wrong, where do >> I submit the list of people I'd like to see excluded from the >> community? >> >> There should not be a long list of people, but when someone is behaving >> unprofessionally, calling people "coconut", being defamatory towards the >> RIPE NCC, ignoring WG chairs, I do think that they have gone too far and >> everything has a limit. >> Like we wouldn't allow someone to send sales emails to the mailing list >> as an example, aka limits on what is allowed. >> >> - Cynthia >> >> On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] >> wrote: >> >> On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >> >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >> >with the RIPE Community (via Meetings or mailing lists) due to his >> blatant >> >disregard for the Code of Conduct and for being hostile towards others in >> >the community. As the RIPE NCC hosts and manages these lists I think the >> >RIPE NCC has a responsibility to keep the lists professional and to >> remove >> >those who repeatedly ignore what the WG chairs are saying. >> >> The RIPE *NCC* has no business either enforcing "professionality" >> on the *community* mailing lists - this is the WG chairs' >> responsibility. Nor do I think the NCC should determine who can >> be a member of the RIPE community or not. If I'm wrong, where do >> I submit the list of people I'd like to see excluded from the >> community? >> I think this proposal is the most out-of-order thing I've yet >> seen in this thread. >> >> rgds, >> Sascha Luck >> >> > >> >- Cynthia >> >> >_______________________________________________ >> >members-discuss mailing list >> >members-discuss at ripe.net >> >https://lists.ripe.net/mailman/listinfo/members-discuss >> >Unsubscribe: >> https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: >> https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re >> >> > _______________________________________________ > members-discuss mailing listmembers-discuss at ripe.nethttps://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/a.morreale%40tradingnetwork.it > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/munir%40aeserver.com > -- *MUNIR BADR* Book A Call: Click here Sales Hotline: *800 123 123* | Intl: +971 4 2493030 -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Mon Apr 27 14:09:27 2020 From: elad at netstyle.io (Elad Cohen) Date: Mon, 27 Apr 2020 12:09:27 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <09ce01d61c88$004ca000$00e5e000$@cloudunboxed.net> References: <20200427104032.GU2680@cilantro.c4inet.net>, , <09ce01d61c88$004ca000$00e5e000$@cloudunboxed.net> Message-ID: Anthony, Everything that you wrote here are false and incorrect, I only responded to a person that was called an antisemitic and a racist, not by me, but by many other people in the Nanog list. * There is comments that ?could? be considered defamatory ? especially when there is limited to no evidence to prove the comment * You continue to harass/bully/attack other members of the list just because they don?t agree with your opinion * You are continuing to throw accusations around again without material evidence. * You are wishing to run for a position of authority which arguably calls you to a far higher standard with regards to how you put your message across My comments below in green regarding the fallacies that you raised: * The required infrastructure globally would be phenomenal - Spamhaus already have such infrastructure in place and they are being sponsored (they don't sell a service at spamhaus.org), so it is feasible * It would also require far more systems level expertise than is realised (think database replication/caching etc) ? especially when you compare this to say, operating one of the root level nameservers or AS112 or RPKI - If system are designed well and developed well then maintenance is low, I don't see this problem as you do * It would for many place an unacceptable ?single? point of failure in your proposed system - Bgp anycast deployment will avoid it * Who would pay for this service? How? What is the pricing model? - RIRs + ccTLDs Registries , and after it the many site owners that will want their newsletters to reach the mailboxes with 100% reliability * Centralising the management has issues - for stability issues bgp anycast will be used, for security and privacy issues - hashing will be used, currently each newsletter subscribers are also centralized, for example mailchimp is a centralized service with many 'mailing list' email addresses. And mailing lists owner will not be obligated to use NoSpam.org - they will still be able to use MailChimp or to save their newsletter system locally - in this case they shouldn't send newselleter with links/images/url's - if their subscribers are using upgraded email clients, simple mailing lists with simple plain text will reach the inboxes - no matter if the domain owner will choose to create a mailing list through NoSpam.org or to implement it on his server with a 3rd party newsletter software. * DATA protection/GPDR compliance ? just because its hashed doesn?t make you any less responsible - There will be a checkbox in the registration form for the end-user for accepting terms and privacy policy, and any domain owner that will open an account at NoSpam.org will also have a checkbox that he read the terms and privacy policy. * Risk of hash collisions? ? is this an issue to be concerned about? It's a good point, hashes can be splited - meaning that each email address will have two hashes - for the two parts before and after @ , in order to minimize the risk of hash collision, in a rare case of collision the end-user will see a newsletter that was emailed directly to him but the user didn't subscribe for it, the user will be able to blacklist. * Like Root Certificates ? getting mail client vendors to update just for your system is going to be exceptionally difficult if not impossible) - once the 5 RIRs and the ccTLDs are ready for this task - I believe that with all of their power it will be possible to recruit client vendors to update. Respectfully, Elad ________________________________ From: anthony.somerset at cloudunboxed.net Sent: Monday, April 27, 2020 2:35 PM To: Elad Cohen ; 'Cynthia Revstr?m' ; 'Sascha Luck [ml]' Cc: members-discuss at ripe.net Subject: RE: [members-discuss] Regarding Elad Cohen's nomination and emails Wow well over 100 emails over the weekend on this topic? For the record ? I have no ties to the Spamhaus project, I don?t personally use it and I can?t say I knowingly know anyone connected to the project in any material way Elad ? your behaviour and your responses continue to be inflammatory in nature (among other things) despite a good many people saying enough now. Please just stop. Its one thing to have an opinion and air it ? I would not want to prevent this from happening but its another thing entirely when * There is comments that ?could? be considered defamatory ? especially when there is limited to no evidence to prove the comment * You continue to harass/bully/attack other members of the list just because they don?t agree with your opinion * You are continuing to throw accusations around again without material evidence. * You are wishing to run for a position of authority which arguably calls you to a far higher standard with regards to how you put your message across Remember you have a right to your opinion, just like we also respectively have the right not to listen to it and/or pick it apart as long as we all keep things civilised and follow the relevant good conduct guidelines in effect. This behaviour would quite frankly get you fired at many companies so why do you consider it acceptable here? You ultimately only are making yourself look worse To the Ripe NCC Moderators/Admin team ? if there is some formal channel that I can now make my complaint known or to request at the very least an immediate moderation of Elad Cohen?s submissions to this mailing list please urgently advise. I would like to formally agree with Cynthia and others? complaints on this matter Back to the ?idea? that triggered this particular wave of arguments, there are a huge number of fallacies with the idea * The required infrastructure globally would be phenomenal * It would also require far more systems level expertise than is realised (think database replication/caching etc) ? especially when you compare this to say, operating one of the root level nameservers or AS112 or RPKI * It would for many place an unacceptable ?single? point of failure in your proposed system * Who would pay for this service? How? What is the pricing model? * Centralising the management has issues * DATA protection/GPDR compliance ? just because its hashed doesn?t make you any less responsible * Risk of hash collisions? ? is this an issue to be concerned about? * Like Root Certificates ? getting mail client vendors to update just for your system is going to be exceptionally difficult if not impossible) Now on the matter of centralising the running of such a system is problematic, especially when you consider that this system is fundamentally a trust based system, you are relying in faith that the responsible guardians of said systems are to be trusted to act responsibly and not to the detriment of others. For some operators in the internet space there are known issues of people doing bad stuff (BGP hijacking, internet shutdowns etc) and I know of at least one RIR (not RIPE) that has not exactly operated fully within their own constitutional mandate and processes in recent times. A good friend of mine and work colleague, Andrew Alston, recently wrote a related article about trust and centralisation as it relates to RPKI - https://www.linkedin.com/pulse/rpki-things-being-considered-andrew-alston/ a lot of the comments made there probably equally apply to any proposed mail filtering solution. To be totally frank ? the only real way to solve the email spam problem is just to turn off email entirely and replace it with some other better architected solution, everything else is realistically a band-aid that people will find ways around. Kind Regards Anthony Somerset From: members-discuss On Behalf Of Elad Cohen Sent: Monday, April 27, 2020 12:59 PM To: Cynthia Revstr?m ; Sascha Luck [ml] Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.naveed at go.com.sa Mon Apr 27 14:18:55 2020 From: a.naveed at go.com.sa (Atif Naveed) Date: Mon, 27 Apr 2020 12:18:55 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net>, , <09ce01d61c88$004ca000$00e5e000$@cloudunboxed.net> Message-ID: Dear Elad, I was one of them who appreciated your idea and promoted, but to keep the discussion on this forum will not earn you much. You need to put this on the table to the right forum so it can be treated seriously and healthy debate make it acceptable. I hope you track down your path towards next stage. regards Atif Naveed From: members-discuss On Behalf Of Elad Cohen Sent: Monday, April 27, 2020 3:09 PM To: anthony.somerset at cloudunboxed.net; 'Cynthia Revstr?m' ; 'Sascha Luck [ml]' Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Anthony, Everything that you wrote here are false and incorrect, I only responded to a person that was called an antisemitic and a racist, not by me, but by many other people in the Nanog list. * There is comments that "could" be considered defamatory - especially when there is limited to no evidence to prove the comment * You continue to harass/bully/attack other members of the list just because they don't agree with your opinion * You are continuing to throw accusations around again without material evidence. * You are wishing to run for a position of authority which arguably calls you to a far higher standard with regards to how you put your message across My comments below in green regarding the fallacies that you raised: * The required infrastructure globally would be phenomenal - Spamhaus already have such infrastructure in place and they are being sponsored (they don't sell a service at spamhaus.org), so it is feasible * It would also require far more systems level expertise than is realised (think database replication/caching etc) - especially when you compare this to say, operating one of the root level nameservers or AS112 or RPKI - If system are designed well and developed well then maintenance is low, I don't see this problem as you do * It would for many place an unacceptable "single" point of failure in your proposed system - Bgp anycast deployment will avoid it * Who would pay for this service? How? What is the pricing model? - RIRs + ccTLDs Registries , and after it the many site owners that will want their newsletters to reach the mailboxes with 100% reliability * Centralising the management has issues - for stability issues bgp anycast will be used, for security and privacy issues - hashing will be used, currently each newsletter subscribers are also centralized, for example mailchimp is a centralized service with many 'mailing list' email addresses. And mailing lists owner will not be obligated to use NoSpam.org - they will still be able to use MailChimp or to save their newsletter system locally - in this case they shouldn't send newselleter with links/images/url's - if their subscribers are using upgraded email clients, simple mailing lists with simple plain text will reach the inboxes - no matter if the domain owner will choose to create a mailing list through NoSpam.org or to implement it on his server with a 3rd party newsletter software. * DATA protection/GPDR compliance - just because its hashed doesn't make you any less responsible - There will be a checkbox in the registration form for the end-user for accepting terms and privacy policy, and any domain owner that will open an account at NoSpam.org will also have a checkbox that he read the terms and privacy policy. * Risk of hash collisions? - is this an issue to be concerned about? It's a good point, hashes can be splited - meaning that each email address will have two hashes - for the two parts before and after @ , in order to minimize the risk of hash collision, in a rare case of collision the end-user will see a newsletter that was emailed directly to him but the user didn't subscribe for it, the user will be able to blacklist. * Like Root Certificates - getting mail client vendors to update just for your system is going to be exceptionally difficult if not impossible) - once the 5 RIRs and the ccTLDs are ready for this task - I believe that with all of their power it will be possible to recruit client vendors to update. Respectfully, Elad ________________________________ From: anthony.somerset at cloudunboxed.net > Sent: Monday, April 27, 2020 2:35 PM To: Elad Cohen >; 'Cynthia Revstr?m' >; 'Sascha Luck [ml]' > Cc: members-discuss at ripe.net > Subject: RE: [members-discuss] Regarding Elad Cohen's nomination and emails Wow well over 100 emails over the weekend on this topic... For the record - I have no ties to the Spamhaus project, I don't personally use it and I can't say I knowingly know anyone connected to the project in any material way Elad - your behaviour and your responses continue to be inflammatory in nature (among other things) despite a good many people saying enough now. Please just stop. Its one thing to have an opinion and air it - I would not want to prevent this from happening but its another thing entirely when * There is comments that "could" be considered defamatory - especially when there is limited to no evidence to prove the comment * You continue to harass/bully/attack other members of the list just because they don't agree with your opinion * You are continuing to throw accusations around again without material evidence. * You are wishing to run for a position of authority which arguably calls you to a far higher standard with regards to how you put your message across Remember you have a right to your opinion, just like we also respectively have the right not to listen to it and/or pick it apart as long as we all keep things civilised and follow the relevant good conduct guidelines in effect. This behaviour would quite frankly get you fired at many companies so why do you consider it acceptable here? You ultimately only are making yourself look worse To the Ripe NCC Moderators/Admin team - if there is some formal channel that I can now make my complaint known or to request at the very least an immediate moderation of Elad Cohen's submissions to this mailing list please urgently advise. I would like to formally agree with Cynthia and others' complaints on this matter Back to the "idea" that triggered this particular wave of arguments, there are a huge number of fallacies with the idea * The required infrastructure globally would be phenomenal * It would also require far more systems level expertise than is realised (think database replication/caching etc) - especially when you compare this to say, operating one of the root level nameservers or AS112 or RPKI * It would for many place an unacceptable "single" point of failure in your proposed system * Who would pay for this service? How? What is the pricing model? * Centralising the management has issues * DATA protection/GPDR compliance - just because its hashed doesn't make you any less responsible * Risk of hash collisions? - is this an issue to be concerned about? * Like Root Certificates - getting mail client vendors to update just for your system is going to be exceptionally difficult if not impossible) Now on the matter of centralising the running of such a system is problematic, especially when you consider that this system is fundamentally a trust based system, you are relying in faith that the responsible guardians of said systems are to be trusted to act responsibly and not to the detriment of others. For some operators in the internet space there are known issues of people doing bad stuff (BGP hijacking, internet shutdowns etc) and I know of at least one RIR (not RIPE) that has not exactly operated fully within their own constitutional mandate and processes in recent times. A good friend of mine and work colleague, Andrew Alston, recently wrote a related article about trust and centralisation as it relates to RPKI - https://www.linkedin.com/pulse/rpki-things-being-considered-andrew-alston/ a lot of the comments made there probably equally apply to any proposed mail filtering solution. To be totally frank - the only real way to solve the email spam problem is just to turn off email entirely and replace it with some other better architected solution, everything else is realistically a band-aid that people will find ways around. Kind Regards Anthony Somerset From: members-discuss > On Behalf Of Elad Cohen Sent: Monday, April 27, 2020 12:59 PM To: Cynthia Revstr?m >; Sascha Luck [ml] > Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hans.Govenius at devnet.fi Mon Apr 27 14:19:30 2020 From: Hans.Govenius at devnet.fi (Hans Govenius) Date: Mon, 27 Apr 2020 12:19:30 +0000 Subject: [members-discuss] Unsubscribing Message-ID: <4034607097129641A4150790179904F5B2E435B7@ex10mdb8.wmhost.com> Hello I promised, nothing more on the topic. And there aint. Many are trying to unsubscribe and many are accusing someone trying to unsubscribe them without permission/to do harm etc. I think this is simply a simple misunderstanding. When there people who say they hit time and time again the unsubscribe button and nothing helps I think you are pressing these links on the emails for example: >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re This is now the last rows on this matter. If I would just press this and hope to be unsubscribed, it would maybe not happen. I would try to unsubscribe Cyntia I guess? I would be left wondering that I didn?t get out of the list and Cynthia would be sending Spy?s and police after my IP ? Atleast im quite sure those both cant work. Either both are not working for *ME* or only one of them is working? Or then I can only unsubscribe after I have actually sent a message and I might then get this unsub link which would work for me? br. Hans L?hett?j?: members-discuss Puolesta Elad Cohen L?hetetty: maanantai 27. huhtikuuta 2020 13.59 Vastaanottaja: Cynthia Revstr?m ; Sascha Luck [ml] Kopio: members-discuss at ripe.net Aihe: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.izzard at imcisland.is Mon Apr 27 14:23:18 2020 From: chris.izzard at imcisland.is (Chris Izzard) Date: Mon, 27 Apr 2020 12:23:18 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <2d3783da-27ae-32b6-8dec-d4e4e1f5481d@tradingnetwork.it> References: <20200427104032.GU2680@cilantro.c4inet.net> <2d3783da-27ae-32b6-8dec-d4e4e1f5481d@tradingnetwork.it> Message-ID: Dear Fellow Members, Please give me a little of your time and read what I have to say. This is my first or second email and I have no axe to grind with anyone as far as I know. I always check back my Friday emails every Monday morning because I deal with people worldwide, this abomination first appeared in my inbox at 09:44 on Friday. Standing back I would say that this email chain shows up a number of deficiencies * We cannot allow Anti-Semitism in any form. * We need some kind of policing of this group email to stop abuse in whatever form it happens. * We need a mechanism that actually takes up accusations and claims because this group is losing relevance because of it. * In the same way we need someone or some people to investigate at a high level and to be able to instigate a full investigation where it is deemed necessary. * It does seem that this group has nobody in control at the present time because I for one would have put a stop to this after a couple of emails. It is not difficult to do. * In short this group need to become relevant again. I propose the following is investigated ASAP and we need a report back within 30 days: 1. Accusations of Anti-Semitism 2. Accusations against Spamhaus. I am lucky being English because English is my native language, it is complicated so I understand misunderstandings can easily happen. We need to treat this like COVID-19 and self-isolate and return in a better condition than we are now. Regards Chris Izzard Director of Commercial Operations IMC Island Ehf Skipholt 50b 105 Reykjavik Iceland PLMN Code: ISLVW Mob: +44 7968 602 280 Mob: +354 389013 343 Skype: chris.izzard From: members-discuss On Behalf Of TNC - Alessandro Morreale Sent: Monday, April 27, 2020 13:02 To: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Is there any good guy that can exclude me from this conversation? It seems the unsubscribe link I used several times doesn't work and, to be honest over 170 messages from this group in last two days it's really too much thanks fof your comprehension Il 27/04/20 13:50, Cynthia Revstr?m ha scritto: Hi Elad, There are 3 major differences I see here, 1. rfg presents lots of evidence that you would have been involved in shady things (I am not sure if they are true and frankly I don't have time currently to look at all of the documents) Meanwhile you are saying that people are part of "The illegal anonymous Spamhaus Project" just because they disagree with you, and as you have said that I am involved in Spamhaus, I would like for you to give me any proof that I am involved with spamhaus in any way (which I am not). 2. rfg called you a "crook", which means dishonest or illegal, which would be true if the things rfg stated are in fact true. Meanwhile you called rfg a "coconut" which can't be anything other than an insult referring to you thinking he is dumb. 3. rfg called you a "crook" once in a long email after describing why he thinks you are a "crook", meanwhile you sent an email that I have posted in its entirety below. > START Michael, Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. Respectfully, Elad > END Please just stop it Elad. Now I still think it was wrong of rfg to use that word, but it is not at all the same thing in my eyes. - Cynthia On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen > wrote: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301.html These are all complete lies only because I found out who are the real people behind "The Spamhaus Project" You can see how he is calling me there Everything there are lies and fake, the "source" for the fake media report is a member of "The Spamhaus Project" and also an employee of a direct competitor (that enjoyed from that fake media report) of a company which used the netblock, and the "source" is also the owner of that criminal twitter account: https://twitter.com/UnderTheBreach , he is a master of cyber influence operations according to his own words in his criminal twitter account and also a member of your cyber-security community. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:14 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, please send me an archive link to the specific email on a RIPE/RIPE NCC mailing list where RFG called you a rude name. - Cynthia On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen > wrote: He called me with antisemitic names many times and on many working groups and you said nothing, you claim not to see his messages, but you clearly saw all of my messages and you are monitoring me pretty well. I'm sorry but I don't believe you, specially when you are attacking me personally so heavily with distorting the facts. You clearly so the word coconut - so you also saw what I shared on the same post that he wrote on other groups of people and that he was called a racist and an antisemitic - but you decided to ignore this as well, so you didn't read my whole post - you read only the word 'coconut' and you decided to jump in ? Cynthia, please spread your lies somewhere else. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:05 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, first of all, I am not an employee or in any way related to Spamhaus, and I doubt many of the people you have suggested are part of it have anything to do with it either. And because I have things to do that are not spending my entire days on RIPE mailing lists I guess I missed RFG calling you names, but I will assure you that if I was on those discussions I would call him out if he called you a "coconut" or similar. Also just because someone has called you names on mailing lists doesn't mean you get to call them names on mailing lists. - Cynthia On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen > wrote: Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/a.morreale%40tradingnetwork.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.somerset at cloudunboxed.net Mon Apr 27 13:35:45 2020 From: anthony.somerset at cloudunboxed.net (anthony.somerset at cloudunboxed.net) Date: Mon, 27 Apr 2020 13:35:45 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net>, Message-ID: <09ce01d61c88$004ca000$00e5e000$@cloudunboxed.net> Wow well over 100 emails over the weekend on this topic For the record ? I have no ties to the Spamhaus project, I don?t personally use it and I can?t say I knowingly know anyone connected to the project in any material way Elad ? your behaviour and your responses continue to be inflammatory in nature (among other things) despite a good many people saying enough now. Please just stop. Its one thing to have an opinion and air it ? I would not want to prevent this from happening but its another thing entirely when * There is comments that ?could? be considered defamatory ? especially when there is limited to no evidence to prove the comment * You continue to harass/bully/attack other members of the list just because they don?t agree with your opinion * You are continuing to throw accusations around again without material evidence. * You are wishing to run for a position of authority which arguably calls you to a far higher standard with regards to how you put your message across Remember you have a right to your opinion, just like we also respectively have the right not to listen to it and/or pick it apart as long as we all keep things civilised and follow the relevant good conduct guidelines in effect. This behaviour would quite frankly get you fired at many companies so why do you consider it acceptable here? You ultimately only are making yourself look worse To the Ripe NCC Moderators/Admin team ? if there is some formal channel that I can now make my complaint known or to request at the very least an immediate moderation of Elad Cohen?s submissions to this mailing list please urgently advise. I would like to formally agree with Cynthia and others? complaints on this matter Back to the ?idea? that triggered this particular wave of arguments, there are a huge number of fallacies with the idea * The required infrastructure globally would be phenomenal * It would also require far more systems level expertise than is realised (think database replication/caching etc) ? especially when you compare this to say, operating one of the root level nameservers or AS112 or RPKI * It would for many place an unacceptable ?single? point of failure in your proposed system * Who would pay for this service? How? What is the pricing model? * Centralising the management has issues * DATA protection/GPDR compliance ? just because its hashed doesn?t make you any less responsible * Risk of hash collisions? ? is this an issue to be concerned about? * Like Root Certificates ? getting mail client vendors to update just for your system is going to be exceptionally difficult if not impossible) Now on the matter of centralising the running of such a system is problematic, especially when you consider that this system is fundamentally a trust based system, you are relying in faith that the responsible guardians of said systems are to be trusted to act responsibly and not to the detriment of others. For some operators in the internet space there are known issues of people doing bad stuff (BGP hijacking, internet shutdowns etc) and I know of at least one RIR (not RIPE) that has not exactly operated fully within their own constitutional mandate and processes in recent times. A good friend of mine and work colleague, Andrew Alston, recently wrote a related article about trust and centralisation as it relates to RPKI - https://www.linkedin.com/pulse/rpki-things-being-considered-andrew-alston/ a lot of the comments made there probably equally apply to any proposed mail filtering solution. To be totally frank ? the only real way to solve the email spam problem is just to turn off email entirely and replace it with some other better architected solution, everything else is realistically a band-aid that people will find ways around. Kind Regards Anthony Somerset From: members-discuss On Behalf Of Elad Cohen Sent: Monday, April 27, 2020 12:59 PM To: Cynthia Revstr?m ; Sascha Luck [ml] Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad _____ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-md at c4inet.net Mon Apr 27 14:30:38 2020 From: ripe-md at c4inet.net (Sascha Luck [ml]) Date: Mon, 27 Apr 2020 13:30:38 +0100 Subject: [members-discuss] Unsubscribing In-Reply-To: <4034607097129641A4150790179904F5B2E435B7@ex10mdb8.wmhost.com> References: <4034607097129641A4150790179904F5B2E435B7@ex10mdb8.wmhost.com> Message-ID: <20200427123038.GX2680@cilantro.c4inet.net> A hint to all who are trying to unsubscribe: *Your* unsubscribe link contains *your* email address. Otherwise you are trying to unsubscribe other members. rgds, Sascha Luck (up to ~30 unsubscribe confirmation emails now) On Mon, Apr 27, 2020 at 12:19:30PM +0000, Hans Govenius wrote: >Hello > >I promised, nothing more on the topic. And there aint. > >Many are trying to unsubscribe and many are accusing someone trying to unsubscribe them without permission/to do harm etc. I think this is simply a simple misunderstanding. > >When there people who say they hit time and time again the unsubscribe button and nothing helps I think you are pressing these links on the emails for example: >>_______________________________________________ >>members-discuss mailing list >>members-discuss at ripe.net >>https://lists.ripe.net/mailman/listinfo/members-discuss >>Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net > > >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re > > >This is now the last rows on this matter. If I would just press this and hope to be unsubscribed, it would maybe not happen. I would try to unsubscribe Cyntia I guess? I would be left wondering that I didn???t get out of the list and Cynthia would be sending Spy??s and police after my IP ???? Atleast im quite sure those both cant work. Either both are not working for *ME* or only one of them is working??? Or then I can only unsubscribe after I have actually sent a message and I might then get this unsub link which would work for me? > >br. Hans > > >L??hett??j??: members-discuss Puolesta Elad Cohen >L??hetetty: maanantai 27. huhtikuuta 2020 13.59 >Vastaanottaja: Cynthia Revstr??m ; Sascha Luck [ml] >Kopio: members-discuss at ripe.net >Aihe: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > >Cynthia, > >The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. > >In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. > >Respectfully, >Elad >________________________________ >From: members-discuss > on behalf of Cynthia Revstr??m > >Sent: Monday, April 27, 2020 1:50 PM >To: Sascha Luck [ml] > >Cc: members-discuss at ripe.net > >Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > >> The RIPE *NCC* has no business either enforcing "professionality" >on the *community* mailing lists - this is the WG chairs' >responsibility. > >AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. > >I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. >Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > >> If I'm wrong, where do >I submit the list of people I'd like to see excluded from the >community? > >There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. >Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. > >- Cynthia > >On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: >On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >>I would like to propose that the RIPE NCC ban Elad Cohen from interacting >>with the RIPE Community (via Meetings or mailing lists) due to his blatant >>disregard for the Code of Conduct and for being hostile towards others in >>the community. As the RIPE NCC hosts and manages these lists I think the >>RIPE NCC has a responsibility to keep the lists professional and to remove >>those who repeatedly ignore what the WG chairs are saying. > >The RIPE *NCC* has no business either enforcing "professionality" >on the *community* mailing lists - this is the WG chairs' >responsibility. Nor do I think the NCC should determine who can >be a member of the RIPE community or not. If I'm wrong, where do >I submit the list of people I'd like to see excluded from the >community? >I think this proposal is the most out-of-order thing I've yet >seen in this thread. > >rgds, >Sascha Luck > >> >>- Cynthia > >>_______________________________________________ >>members-discuss mailing list >>members-discuss at ripe.net >>https://lists.ripe.net/mailman/listinfo/members-discuss >>Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net > > >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re From anthony.somerset at cloudunboxed.net Mon Apr 27 14:31:00 2020 From: anthony.somerset at cloudunboxed.net (anthony.somerset at cloudunboxed.net) Date: Mon, 27 Apr 2020 14:31:00 +0200 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net>, , <09ce01d61c88$004ca000$00e5e000$@cloudunboxed.net> Message-ID: <0a2401d61c8f$b8c09c20$2a41d460$@cloudunboxed.net> Hi Elad I?m glad you have come back with cogent rebuttals to my pointing out short comings I?d like to state that many of the matters I raised are not unsurmountable but whether they are economically and technically feasible does remain to be seen. A working POC would better demonstrate this. I will advise specifically that just thinking BGP anycast alone will solve all your problems is fairly short sighted. To give an example, Database replication cannot be simply engineered into being with BGP anycast only. Once a system is in operation yes maintenance might be relatively low but the level of expertise to implement such a complex system should not be under-estimated. It would need one extremely well co-ordinated team for initial project and it would still need a reasonably well resourced team to maintain going forward because again database replication for one is not something you can set and forget, its health needs to be carefully and continuously monitored. I can?t speak in much more depth because there isn?t a detailed technical architecture to comment on at this stage. These are just some of the things you would need to consider and architect around The main problems of your proposal are still fundamentally trust based and the need to get the entire ecosystem using it for it to actually work, and you can refer to the whole IPv6 rollout as a good example of the difficulties of getting worldwide adoption ? it will take years even if you get the RIR?s and ccTLD?s on board! I still don?t see a sensible way of gaining trust in a centralised management model and I unfortunately don?t have any better suggestions at this time for the specific use case From: Elad Cohen Sent: Monday, April 27, 2020 2:09 PM To: anthony.somerset at cloudunboxed.net; 'Cynthia Revstr?m' ; 'Sascha Luck [ml]' Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Anthony, Everything that you wrote here are false and incorrect, I only responded to a person that was called an antisemitic and a racist, not by me, but by many other people in the Nanog list. * There is comments that ?could? be considered defamatory ? especially when there is limited to no evidence to prove the comment * You continue to harass/bully/attack other members of the list just because they don?t agree with your opinion * You are continuing to throw accusations around again without material evidence. * You are wishing to run for a position of authority which arguably calls you to a far higher standard with regards to how you put your message across My comments below in green regarding the fallacies that you raised: * The required infrastructure globally would be phenomenal - Spamhaus already have such infrastructure in place and they are being sponsored (they don't sell a service at spamhaus.org), so it is feasible * It would also require far more systems level expertise than is realised (think database replication/caching etc) ? especially when you compare this to say, operating one of the root level nameservers or AS112 or RPKI - If system are designed well and developed well then maintenance is low, I don't see this problem as you do * It would for many place an unacceptable ?single? point of failure in your proposed system - Bgp anycast deployment will avoid it * Who would pay for this service? How? What is the pricing model? - RIRs + ccTLDs Registries , and after it the many site owners that will want their newsletters to reach the mailboxes with 100% reliability * Centralising the management has issues - for stability issues bgp anycast will be used, for security and privacy issues - hashing will be used, currently each newsletter subscribers are also centralized, for example mailchimp is a centralized service with many 'mailing list' email addresses. And mailing lists owner will not be obligated to use NoSpam.org - they will still be able to use MailChimp or to save their newsletter system locally - in this case they shouldn't send newselleter with links/images/url's - if their subscribers are using upgraded email clients, simple mailing lists with simple plain text will reach the inboxes - no matter if the domain owner will choose to create a mailing list through NoSpam.org or to implement it on his server with a 3rd party newsletter software. * DATA protection/GPDR compliance ? just because its hashed doesn?t make you any less responsible - There will be a checkbox in the registration form for the end-user for accepting terms and privacy policy, and any domain owner that will open an account at NoSpam.org will also have a checkbox that he read the terms and privacy policy. * Risk of hash collisions? ? is this an issue to be concerned about? It's a good point, hashes can be splited - meaning that each email address will have two hashes - for the two parts before and after @ , in order to minimize the risk of hash collision, in a rare case of collision the end-user will see a newsletter that was emailed directly to him but the user didn't subscribe for it, the user will be able to blacklist. * Like Root Certificates ? getting mail client vendors to update just for your system is going to be exceptionally difficult if not impossible) - once the 5 RIRs and the ccTLDs are ready for this task - I believe that with all of their power it will be possible to recruit client vendors to update. Respectfully, Elad _____ From: anthony.somerset at cloudunboxed.net > Sent: Monday, April 27, 2020 2:35 PM To: Elad Cohen >; 'Cynthia Revstr?m' >; 'Sascha Luck [ml]' > Cc: members-discuss at ripe.net > Subject: RE: [members-discuss] Regarding Elad Cohen's nomination and emails Wow well over 100 emails over the weekend on this topic For the record ? I have no ties to the Spamhaus project, I don?t personally use it and I can?t say I knowingly know anyone connected to the project in any material way Elad ? your behaviour and your responses continue to be inflammatory in nature (among other things) despite a good many people saying enough now. Please just stop. Its one thing to have an opinion and air it ? I would not want to prevent this from happening but its another thing entirely when * There is comments that ?could? be considered defamatory ? especially when there is limited to no evidence to prove the comment * You continue to harass/bully/attack other members of the list just because they don?t agree with your opinion * You are continuing to throw accusations around again without material evidence. * You are wishing to run for a position of authority which arguably calls you to a far higher standard with regards to how you put your message across Remember you have a right to your opinion, just like we also respectively have the right not to listen to it and/or pick it apart as long as we all keep things civilised and follow the relevant good conduct guidelines in effect. This behaviour would quite frankly get you fired at many companies so why do you consider it acceptable here? You ultimately only are making yourself look worse To the Ripe NCC Moderators/Admin team ? if there is some formal channel that I can now make my complaint known or to request at the very least an immediate moderation of Elad Cohen?s submissions to this mailing list please urgently advise. I would like to formally agree with Cynthia and others? complaints on this matter Back to the ?idea? that triggered this particular wave of arguments, there are a huge number of fallacies with the idea * The required infrastructure globally would be phenomenal * It would also require far more systems level expertise than is realised (think database replication/caching etc) ? especially when you compare this to say, operating one of the root level nameservers or AS112 or RPKI * It would for many place an unacceptable ?single? point of failure in your proposed system * Who would pay for this service? How? What is the pricing model? * Centralising the management has issues * DATA protection/GPDR compliance ? just because its hashed doesn?t make you any less responsible * Risk of hash collisions? ? is this an issue to be concerned about? * Like Root Certificates ? getting mail client vendors to update just for your system is going to be exceptionally difficult if not impossible) Now on the matter of centralising the running of such a system is problematic, especially when you consider that this system is fundamentally a trust based system, you are relying in faith that the responsible guardians of said systems are to be trusted to act responsibly and not to the detriment of others. For some operators in the internet space there are known issues of people doing bad stuff (BGP hijacking, internet shutdowns etc) and I know of at least one RIR (not RIPE) that has not exactly operated fully within their own constitutional mandate and processes in recent times. A good friend of mine and work colleague, Andrew Alston, recently wrote a related article about trust and centralisation as it relates to RPKI - https://www.linkedin.com/pulse/rpki-things-being-considered-andrew-alston/ a lot of the comments made there probably equally apply to any proposed mail filtering solution. To be totally frank ? the only real way to solve the email spam problem is just to turn off email entirely and replace it with some other better architected solution, everything else is realistically a band-aid that people will find ways around. Kind Regards Anthony Somerset From: members-discuss < members-discuss-bounces at ripe.net> On Behalf Of Elad Cohen Sent: Monday, April 27, 2020 12:59 PM To: Cynthia Revstr?m < me at cynthia.re>; Sascha Luck [ml] < ripe-md at c4inet.net> Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad _____ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Mon Apr 27 14:36:05 2020 From: elad at netstyle.io (Elad Cohen) Date: Mon, 27 Apr 2020 12:36:05 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net> , Message-ID: This is amazing how the illegal anonymous "The Spamhaus Project" members keep twisting the facts. Cynthia, Zero evidence was provided, not even a single proof, but still you claim "lots of evidence" I didn't say that anyone is part of "The Spamhaus Project" because disagree with me, I said that anyone is part of the illegal anonymous organization "The Spamhaus Project" because he is part of the illegal anonymous organization "The Spamhaus Project" - see how much you are personally targeting me - see how much you are protecting your sick friend RFG. Please don't interpret me - coconut means coconut - RFG is a coconut by anyone that knows him personally. Here is what your sick friend wrote: https://imgur.com/AcmgwEX (his opinion on all Dutch people as a whole - "Dutch are any more inclined toward cybercrime") https://imgur.com/WUZvdNJ (his opinion on all Colombian Network Operators usage of the internet as a whole - "Undoubtedly drug smuggling over HTTP") https://imgur.com/a/1ULfVEC (his opinion on the City of Chicago including all of its citizens as a whole - "American city most known for its high ideals and consistantely ethical behavior, Chicago") https://imgur.com/AQCmZlk (RFG being identified as racist in Nanog) https://imgur.com/a/Rzrbxkz (RFG being identified as antisemitic in Nanog) RFG called me in two names that one of them you wrote, you can keep with your lies and to defend a racist and an antisemitic person - but there is something which is called context, you can see in the first link above that RFG quoted Shakespeare regarding the Netherlands, when he called me in the name that you mentioned he did it after not providing not even a single proof against me and he specially used that name - which also in Shakespeare being referred to jews - you are defending a person which is a racist and an antisemitic according to all the above links. Respectfully, Elad ________________________________ From: Cynthia Revstr?m Sent: Monday, April 27, 2020 2:50 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hi Elad, There are 3 major differences I see here, 1. rfg presents lots of evidence that you would have been involved in shady things (I am not sure if they are true and frankly I don't have time currently to look at all of the documents) Meanwhile you are saying that people are part of "The illegal anonymous Spamhaus Project" just because they disagree with you, and as you have said that I am involved in Spamhaus, I would like for you to give me any proof that I am involved with spamhaus in any way (which I am not). 2. rfg called you a "crook", which means dishonest or illegal, which would be true if the things rfg stated are in fact true. Meanwhile you called rfg a "coconut" which can't be anything other than an insult referring to you thinking he is dumb. 3. rfg called you a "crook" once in a long email after describing why he thinks you are a "crook", meanwhile you sent an email that I have posted in its entirety below. > START Michael, Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. Respectfully, Elad > END Please just stop it Elad. Now I still think it was wrong of rfg to use that word, but it is not at all the same thing in my eyes. - Cynthia On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen > wrote: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301.html These are all complete lies only because I found out who are the real people behind "The Spamhaus Project" You can see how he is calling me there Everything there are lies and fake, the "source" for the fake media report is a member of "The Spamhaus Project" and also an employee of a direct competitor (that enjoyed from that fake media report) of a company which used the netblock, and the "source" is also the owner of that criminal twitter account: https://twitter.com/UnderTheBreach , he is a master of cyber influence operations according to his own words in his criminal twitter account and also a member of your cyber-security community. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:14 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, please send me an archive link to the specific email on a RIPE/RIPE NCC mailing list where RFG called you a rude name. - Cynthia On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen > wrote: He called me with antisemitic names many times and on many working groups and you said nothing, you claim not to see his messages, but you clearly saw all of my messages and you are monitoring me pretty well. I'm sorry but I don't believe you, specially when you are attacking me personally so heavily with distorting the facts. You clearly so the word coconut - so you also saw what I shared on the same post that he wrote on other groups of people and that he was called a racist and an antisemitic - but you decided to ignore this as well, so you didn't read my whole post - you read only the word 'coconut' and you decided to jump in ? Cynthia, please spread your lies somewhere else. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:05 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, first of all, I am not an employee or in any way related to Spamhaus, and I doubt many of the people you have suggested are part of it have anything to do with it either. And because I have things to do that are not spending my entire days on RIPE mailing lists I guess I missed RFG calling you names, but I will assure you that if I was on those discussions I would call him out if he called you a "coconut" or similar. Also just because someone has called you names on mailing lists doesn't mean you get to call them names on mailing lists. - Cynthia On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen > wrote: Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re -------------- next part -------------- An HTML attachment was scrubbed... URL: From Timothy at tra.gov.om Mon Apr 27 14:37:00 2020 From: Timothy at tra.gov.om (Timothy Allen Roy) Date: Mon, 27 Apr 2020 12:37:00 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net> <2d3783da-27ae-32b6-8dec-d4e4e1f5481d@tradingnetwork.it>, Message-ID: This is what I was suggesting in my earlier email, but probably did not say it clear enough and got shot down from the get go. anyway good luck to all and Ramadan Kareem ________________________________ From: members-discuss on behalf of Chris Izzard Sent: Monday, April 27, 2020 4:23 PM To: TNC - Alessandro Morreale; members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Dear Fellow Members, Please give me a little of your time and read what I have to say. This is my first or second email and I have no axe to grind with anyone as far as I know. I always check back my Friday emails every Monday morning because I deal with people worldwide, this abomination first appeared in my inbox at 09:44 on Friday. Standing back I would say that this email chain shows up a number of deficiencies * We cannot allow Anti-Semitism in any form. * We need some kind of policing of this group email to stop abuse in whatever form it happens. * We need a mechanism that actually takes up accusations and claims because this group is losing relevance because of it. * In the same way we need someone or some people to investigate at a high level and to be able to instigate a full investigation where it is deemed necessary. * It does seem that this group has nobody in control at the present time because I for one would have put a stop to this after a couple of emails. It is not difficult to do. * In short this group need to become relevant again. I propose the following is investigated ASAP and we need a report back within 30 days: 1. Accusations of Anti-Semitism 2. Accusations against Spamhaus. I am lucky being English because English is my native language, it is complicated so I understand misunderstandings can easily happen. We need to treat this like COVID-19 and self-isolate and return in a better condition than we are now. Regards Chris Izzard Director of Commercial Operations IMC Island Ehf Skipholt 50b 105 Reykjavik Iceland PLMN Code: ISLVW Mob: +44 7968 602 280 Mob: +354 389013 343 Skype: chris.izzard From: members-discuss On Behalf Of TNC - Alessandro Morreale Sent: Monday, April 27, 2020 13:02 To: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Is there any good guy that can exclude me from this conversation? It seems the unsubscribe link I used several times doesn't work and, to be honest over 170 messages from this group in last two days it's really too much thanks fof your comprehension Il 27/04/20 13:50, Cynthia Revstr?m ha scritto: Hi Elad, There are 3 major differences I see here, 1. rfg presents lots of evidence that you would have been involved in shady things (I am not sure if they are true and frankly I don't have time currently to look at all of the documents) Meanwhile you are saying that people are part of "The illegal anonymous Spamhaus Project" just because they disagree with you, and as you have said that I am involved in Spamhaus, I would like for you to give me any proof that I am involved with spamhaus in any way (which I am not). 2. rfg called you a "crook", which means dishonest or illegal, which would be true if the things rfg stated are in fact true. Meanwhile you called rfg a "coconut" which can't be anything other than an insult referring to you thinking he is dumb. 3. rfg called you a "crook" once in a long email after describing why he thinks you are a "crook", meanwhile you sent an email that I have posted in its entirety below. > START Michael, Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. Respectfully, Elad > END Please just stop it Elad. Now I still think it was wrong of rfg to use that word, but it is not at all the same thing in my eyes. - Cynthia On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen > wrote: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301.html These are all complete lies only because I found out who are the real people behind "The Spamhaus Project" You can see how he is calling me there Everything there are lies and fake, the "source" for the fake media report is a member of "The Spamhaus Project" and also an employee of a direct competitor (that enjoyed from that fake media report) of a company which used the netblock, and the "source" is also the owner of that criminal twitter account: https://twitter.com/UnderTheBreach , he is a master of cyber influence operations according to his own words in his criminal twitter account and also a member of your cyber-security community. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:14 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, please send me an archive link to the specific email on a RIPE/RIPE NCC mailing list where RFG called you a rude name. - Cynthia On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen > wrote: He called me with antisemitic names many times and on many working groups and you said nothing, you claim not to see his messages, but you clearly saw all of my messages and you are monitoring me pretty well. I'm sorry but I don't believe you, specially when you are attacking me personally so heavily with distorting the facts. You clearly so the word coconut - so you also saw what I shared on the same post that he wrote on other groups of people and that he was called a racist and an antisemitic - but you decided to ignore this as well, so you didn't read my whole post - you read only the word 'coconut' and you decided to jump in ? Cynthia, please spread your lies somewhere else. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:05 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, first of all, I am not an employee or in any way related to Spamhaus, and I doubt many of the people you have suggested are part of it have anything to do with it either. And because I have things to do that are not spending my entire days on RIPE mailing lists I guess I missed RFG calling you names, but I will assure you that if I was on those discussions I would call him out if he called you a "coconut" or similar. Also just because someone has called you names on mailing lists doesn't mean you get to call them names on mailing lists. - Cynthia On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen > wrote: Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/a.morreale%40tradingnetwork.it From jon at fido.net Mon Apr 27 14:40:31 2020 From: jon at fido.net (Jon Morby) Date: Mon, 27 Apr 2020 13:40:31 +0100 Subject: [members-discuss] Unsubscribing In-Reply-To: <20200427123038.GX2680@cilantro.c4inet.net> References: <4034607097129641A4150790179904F5B2E435B7@ex10mdb8.wmhost.com> <20200427123038.GX2680@cilantro.c4inet.net> Message-ID: <0781B98A-7132-4649-96B9-AD6E5908F042@fido.net> The problem is the unsubscribe only works for a short period of time before RIPE?s systems auto re-subscribe you You have to log into the RIPE LIR Portal and under My Account you can control which email addresses within your organisation are subscribed ? however you have to have at least 1 member, so if you?re it your other option appear to be /dev/null via a rule or just suck it up I?m guessing it?s because RIPE mandate you must have at least 1 person from an organisation subscribed in order to discuss Membership Related issues The problem here is Elad has abused the list and is posting in the wrong place We?re all then giving him oxygen and the fire is exploding It would be better if we all just ignored the numerous threads, and RIPE woke up and did something about enforcing the rules in both directions (they?ve programmed it so we can?t unsubscribe, but they?re not policing the content so we?re at a point where a mandatory list for discussion of issues relating to MEMBERSHIP of RIPE has been taken over with what amounts to UCE and/or SPAM) just my 2c It also doesn?t help that some organisations have subscribed ticketing systems so every time you post into the members discussion group you get an auto responder :( > On 27 Apr 2020, at 13:30, Sascha Luck [ml] wrote: > > A hint to all who are trying to unsubscribe: > > *Your* unsubscribe link contains *your* email address. Otherwise > you are trying to unsubscribe other members. > > rgds, > Sascha Luck (up to ~30 unsubscribe confirmation emails now) > > On Mon, Apr 27, 2020 at 12:19:30PM +0000, Hans Govenius wrote: >> Hello >> >> I promised, nothing more on the topic. And there aint. >> >> Many are trying to unsubscribe and many are accusing someone trying to unsubscribe them without permission/to do harm etc. I think this is simply a simple misunderstanding. >> >> When there people who say they hit time and time again the unsubscribe button and nothing helps I think you are pressing these links on the emails for example: >>> _______________________________________________ >>> members-discuss mailing list >>> members-discuss at ripe.net >>> https://lists.ripe.net/mailman/listinfo/members-discuss >>> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re >> >> >> This is now the last rows on this matter. If I would just press this and hope to be unsubscribed, it would maybe not happen. I would try to unsubscribe Cyntia I guess? I would be left wondering that I didn?t get out of the list and Cynthia would be sending Spy?s and police after my IP ? Atleast im quite sure those both cant work. Either both are not working for *ME* or only one of them is working? Or then I can only unsubscribe after I have actually sent a message and I might then get this unsub link which would work for me? >> >> br. Hans >> >> >> L?hett?j?: members-discuss Puolesta Elad Cohen >> L?hetetty: maanantai 27. huhtikuuta 2020 13.59 >> Vastaanottaja: Cynthia Revstr?m ; Sascha Luck [ml] >> Kopio: members-discuss at ripe.net >> Aihe: Re: [members-discuss] Regarding Elad Cohen's nomination and emails >> >> Cynthia, >> >> The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. >> >> In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. >> >> Respectfully, >> Elad >> ________________________________ >> From: members-discuss > on behalf of Cynthia Revstr?m > >> Sent: Monday, April 27, 2020 1:50 PM >> To: Sascha Luck [ml] > >> Cc: members-discuss at ripe.net > >> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails >> >>> The RIPE *NCC* has no business either enforcing "professionality" >> on the *community* mailing lists - this is the WG chairs' >> responsibility. >> >> AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. >> >> I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. >> Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. >> >>> If I'm wrong, where do >> I submit the list of people I'd like to see excluded from the >> community? >> >> There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. >> Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. >> >> - Cynthia >> >> On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: >> On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >>> I would like to propose that the RIPE NCC ban Elad Cohen from interacting >>> with the RIPE Community (via Meetings or mailing lists) due to his blatant >>> disregard for the Code of Conduct and for being hostile towards others in >>> the community. As the RIPE NCC hosts and manages these lists I think the >>> RIPE NCC has a responsibility to keep the lists professional and to remove >>> those who repeatedly ignore what the WG chairs are saying. >> >> The RIPE *NCC* has no business either enforcing "professionality" >> on the *community* mailing lists - this is the WG chairs' >> responsibility. Nor do I think the NCC should determine who can >> be a member of the RIPE community or not. If I'm wrong, where do >> I submit the list of people I'd like to see excluded from the >> community? >> I think this proposal is the most out-of-order thing I've yet >> seen in this thread. >> >> rgds, >> Sascha Luck >> >>> >>> - Cynthia >> >>> _______________________________________________ >>> members-discuss mailing list >>> members-discuss at ripe.net >>> https://lists.ripe.net/mailman/listinfo/members-discuss >>> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/jon%40fido.net Jon Morby FidoNet - where those in the know go! web: www.fido.net tel: 0345 004 3050 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.lawrence at nomical.com Mon Apr 27 14:44:16 2020 From: chris.lawrence at nomical.com (Chris Lawrence) Date: Mon, 27 Apr 2020 12:44:16 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net> Message-ID: <385A998E-586A-46CA-87EC-F8F3410836AB@nomical.com> Elad Enough now this is beyond a joke.. Please take your conversations off the list. Regards Chris Chris Lawrence Senior Solutions Architect +44 344 384 3000 +44 7775 871094 nomical.com Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE This email and any attachments are intended for the named recipient only. Its unauthorised use, distribution, disclosure, storage or copying is not permitted. If you have received it in error, please destroy all copies and notify the sender. In messages of a non-business nature, the views and opinions expressed are the author's own and do not necessarily reflect those of the organisation from which it is sent. All emails may be subject to monitoring. Nomical Ltd - Registered in England No: 06035958, VAT Reg No: 900363074, Registered Office: Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE From: members-discuss on behalf of Elad Cohen Date: Monday, 27 April 2020 at 13:43 To: Cynthia Revstr?m , "members-discuss at ripe.net" Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails This is amazing how the illegal anonymous "The Spamhaus Project" members keep twisting the facts. Cynthia, Zero evidence was provided, not even a single proof, but still you claim "lots of evidence" I didn't say that anyone is part of "The Spamhaus Project" because disagree with me, I said that anyone is part of the illegal anonymous organization "The Spamhaus Project" because he is part of the illegal anonymous organization "The Spamhaus Project" - see how much you are personally targeting me - see how much you are protecting your sick friend RFG. Please don't interpret me - coconut means coconut - RFG is a coconut by anyone that knows him personally. Here is what your sick friend wrote: https://imgur.com/AcmgwEX (his opinion on all Dutch people as a whole - "Dutch are any more inclined toward cybercrime") https://imgur.com/WUZvdNJ (his opinion on all Colombian Network Operators usage of the internet as a whole - "Undoubtedly drug smuggling over HTTP") https://imgur.com/a/1ULfVEC (his opinion on the City of Chicago including all of its citizens as a whole - "American city most known for its high ideals and consistantely ethical behavior, Chicago") https://imgur.com/AQCmZlk (RFG being identified as racist in Nanog) https://imgur.com/a/Rzrbxkz (RFG being identified as antisemitic in Nanog) RFG called me in two names that one of them you wrote, you can keep with your lies and to defend a racist and an antisemitic person - but there is something which is called context, you can see in the first link above that RFG quoted Shakespeare regarding the Netherlands, when he called me in the name that you mentioned he did it after not providing not even a single proof against me and he specially used that name - which also in Shakespeare being referred to jews - you are defending a person which is a racist and an antisemitic according to all the above links. Respectfully, Elad ________________________________ From: Cynthia Revstr?m Sent: Monday, April 27, 2020 2:50 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hi Elad, There are 3 major differences I see here, 1. rfg presents lots of evidence that you would have been involved in shady things (I am not sure if they are true and frankly I don't have time currently to look at all of the documents) Meanwhile you are saying that people are part of "The illegal anonymous Spamhaus Project" just because they disagree with you, and as you have said that I am involved in Spamhaus, I would like for you to give me any proof that I am involved with spamhaus in any way (which I am not). 2. rfg called you a "crook", which means dishonest or illegal, which would be true if the things rfg stated are in fact true. Meanwhile you called rfg a "coconut" which can't be anything other than an insult referring to you thinking he is dumb. 3. rfg called you a "crook" once in a long email after describing why he thinks you are a "crook", meanwhile you sent an email that I have posted in its entirety below. > START Michael, Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. Respectfully, Elad > END Please just stop it Elad. Now I still think it was wrong of rfg to use that word, but it is not at all the same thing in my eyes. - Cynthia On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen > wrote: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301.html These are all complete lies only because I found out who are the real people behind "The Spamhaus Project" You can see how he is calling me there Everything there are lies and fake, the "source" for the fake media report is a member of "The Spamhaus Project" and also an employee of a direct competitor (that enjoyed from that fake media report) of a company which used the netblock, and the "source" is also the owner of that criminal twitter account: https://twitter.com/UnderTheBreach , he is a master of cyber influence operations according to his own words in his criminal twitter account and also a member of your cyber-security community. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:14 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, please send me an archive link to the specific email on a RIPE/RIPE NCC mailing list where RFG called you a rude name. - Cynthia On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen > wrote: He called me with antisemitic names many times and on many working groups and you said nothing, you claim not to see his messages, but you clearly saw all of my messages and you are monitoring me pretty well. I'm sorry but I don't believe you, specially when you are attacking me personally so heavily with distorting the facts. You clearly so the word coconut - so you also saw what I shared on the same post that he wrote on other groups of people and that he was called a racist and an antisemitic - but you decided to ignore this as well, so you didn't read my whole post - you read only the word 'coconut' and you decided to jump in ? Cynthia, please spread your lies somewhere else. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:05 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, first of all, I am not an employee or in any way related to Spamhaus, and I doubt many of the people you have suggested are part of it have anything to do with it either. And because I have things to do that are not spending my entire days on RIPE mailing lists I guess I missed RFG calling you names, but I will assure you that if I was on those discussions I would call him out if he called you a "coconut" or similar. Also just because someone has called you names on mailing lists doesn't mean you get to call them names on mailing lists. - Cynthia On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen > wrote: Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-md at c4inet.net Mon Apr 27 14:47:42 2020 From: ripe-md at c4inet.net (Sascha Luck [ml]) Date: Mon, 27 Apr 2020 13:47:42 +0100 Subject: [members-discuss] Unsubscribing In-Reply-To: <0781B98A-7132-4649-96B9-AD6E5908F042@fido.net> References: <4034607097129641A4150790179904F5B2E435B7@ex10mdb8.wmhost.com> <20200427123038.GX2680@cilantro.c4inet.net> <0781B98A-7132-4649-96B9-AD6E5908F042@fido.net> Message-ID: <20200427124742.GY2680@cilantro.c4inet.net> On Mon, Apr 27, 2020 at 01:40:31PM +0100, Jon Morby wrote: >The problem is the unsubscribe only works for a short period of time before RIPE???s systems auto re-subscribe you > >You have to log into the RIPE LIR Portal and under My Account you can control which email addresses within your organisation are subscribed ??? however you have to have at least 1 member, so if you???re it your other option appear to be /dev/null via a rule or just suck it up In that case it may be better if the list server didn't append an unsubscribe link - or at least use a proper signature separator so it doesn't get quoted, leading to 3rd party unsub storms. (Unless someone is doing this maliciously, of course) rgds, Sascha Luck From jon at fido.net Mon Apr 27 15:07:46 2020 From: jon at fido.net (Jon Morby) Date: Mon, 27 Apr 2020 14:07:46 +0100 Subject: [members-discuss] Unsubscribing In-Reply-To: <20200427124742.GY2680@cilantro.c4inet.net> References: <4034607097129641A4150790179904F5B2E435B7@ex10mdb8.wmhost.com> <20200427123038.GX2680@cilantro.c4inet.net> <0781B98A-7132-4649-96B9-AD6E5908F042@fido.net> <20200427124742.GY2680@cilantro.c4inet.net> Message-ID: agreed! Especially as I?m now receiving emails such as We have received a request from 31.148.228.246 for the removal of your email address, Where someone in Spain at Olivenet (in this instance) seems to have tried to unsubscribe me rather than themselves (or are they just trying to be helpful?) Either way, RIPE should probably update the footer they?re appending > On 27 Apr 2020, at 13:47, Sascha Luck [ml] wrote: > > In that case it may be better if the list server didn't append an > unsubscribe link - or at least use a proper signature separator > so it doesn't get quoted, leading to 3rd party unsub storms. > (Unless someone is doing this maliciously, of course) > > rgds, > Sascha Luck Jon Morby FidoNet - where those in the know go! web: www.fido.net tel: 0345 004 3050 -------------- next part -------------- An HTML attachment was scrubbed... URL: From enis.murati at raiffeisen-kosovo.com Mon Apr 27 15:34:57 2020 From: enis.murati at raiffeisen-kosovo.com (Enis MURATI) Date: Mon, 27 Apr 2020 13:34:57 +0000 Subject: [members-discuss] UNSUBSCRIBE In-Reply-To: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> References: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> Message-ID: UNSUBSCRIBE Me nderime/Regards Enis Murati From: members-discuss On Behalf Of David Simmons Sent: Monday, April 27, 2020 1:19 PM To: members-discuss at ripe.net Subject: [members-discuss] UNSUBSCRIBE UNSUBSCRIBE -------------- next part -------------- An HTML attachment was scrubbed... URL: From anpier at fastnet.it Mon Apr 27 15:40:01 2020 From: anpier at fastnet.it (Andrea Pieralisi) Date: Mon, 27 Apr 2020 15:40:01 +0200 Subject: [members-discuss] UNSUBSCRIBE In-Reply-To: References: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> Message-ID: <3be35972-1023-26a5-106d-a8a5f37e9a86@fastnet.it> UNSUBSCRIBE Il 27/04/2020 15:34, Enis MURATI ha scritto: > > UNSUBSCRIBE > > Me nderime/Regards > > *Enis Murati* > > *From:*members-discuss *On Behalf > Of *David Simmons > *Sent:* Monday, April 27, 2020 1:19 PM > *To:* members-discuss at ripe.net > *Subject:* [members-discuss] UNSUBSCRIBE > > UNSUBSCRIBE > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/anpier%40fastnet.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Mon Apr 27 15:43:07 2020 From: elad at netstyle.io (Elad Cohen) Date: Mon, 27 Apr 2020 13:43:07 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: <385A998E-586A-46CA-87EC-F8F3410836AB@nomical.com> References: <20200427104032.GU2680@cilantro.c4inet.net> , <385A998E-586A-46CA-87EC-F8F3410836AB@nomical.com> Message-ID: Chris, This wasn't my conversation, this was my response to an attack on me. Take your fake messages off the list. Respectfully, Elad ________________________________ From: Chris Lawrence Sent: Monday, April 27, 2020 3:44 PM To: Elad Cohen ; Cynthia Revstr?m ; members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad Enough now this is beyond a joke.. Please take your conversations off the list. Regards Chris Chris Lawrence? Senior Solutions Architect +44 344 384 3000 +44 7775 871094 nomical.com Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE This email and any attachments are intended for the named recipient only. Its unauthorised use, distribution, disclosure, storage or copying is not permitted. If you have received it in error, please destroy all copies and notify the sender. In messages of a non-business nature, the views and opinions expressed are the author's own and do not necessarily reflect those of the organisation from which it is sent. All emails may be subject to monitoring. Nomical Ltd - Registered in England No: 06035958, VAT Reg No: 900363074, Registered Office: Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE From: members-discuss on behalf of Elad Cohen Date: Monday, 27 April 2020 at 13:43 To: Cynthia Revstr?m , "members-discuss at ripe.net" Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails This is amazing how the illegal anonymous "The Spamhaus Project" members keep twisting the facts. Cynthia, Zero evidence was provided, not even a single proof, but still you claim "lots of evidence" I didn't say that anyone is part of "The Spamhaus Project" because disagree with me, I said that anyone is part of the illegal anonymous organization "The Spamhaus Project" because he is part of the illegal anonymous organization "The Spamhaus Project" - see how much you are personally targeting me - see how much you are protecting your sick friend RFG. Please don't interpret me - coconut means coconut - RFG is a coconut by anyone that knows him personally. Here is what your sick friend wrote: https://imgur.com/AcmgwEX (his opinion on all Dutch people as a whole - "Dutch are any more inclined toward cybercrime") https://imgur.com/WUZvdNJ (his opinion on all Colombian Network Operators usage of the internet as a whole - "Undoubtedly drug smuggling over HTTP") https://imgur.com/a/1ULfVEC (his opinion on the City of Chicago including all of its citizens as a whole - "American city most known for its high ideals and consistantely ethical behavior, Chicago") https://imgur.com/AQCmZlk (RFG being identified as racist in Nanog) https://imgur.com/a/Rzrbxkz (RFG being identified as antisemitic in Nanog) RFG called me in two names that one of them you wrote, you can keep with your lies and to defend a racist and an antisemitic person - but there is something which is called context, you can see in the first link above that RFG quoted Shakespeare regarding the Netherlands, when he called me in the name that you mentioned he did it after not providing not even a single proof against me and he specially used that name - which also in Shakespeare being referred to jews - you are defending a person which is a racist and an antisemitic according to all the above links. Respectfully, Elad ________________________________ From: Cynthia Revstr?m Sent: Monday, April 27, 2020 2:50 PM To: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hi Elad, There are 3 major differences I see here, 1. rfg presents lots of evidence that you would have been involved in shady things (I am not sure if they are true and frankly I don't have time currently to look at all of the documents) Meanwhile you are saying that people are part of "The illegal anonymous Spamhaus Project" just because they disagree with you, and as you have said that I am involved in Spamhaus, I would like for you to give me any proof that I am involved with spamhaus in any way (which I am not). 2. rfg called you a "crook", which means dishonest or illegal, which would be true if the things rfg stated are in fact true. Meanwhile you called rfg a "coconut" which can't be anything other than an insult referring to you thinking he is dumb. 3. rfg called you a "crook" once in a long email after describing why he thinks you are a "crook", meanwhile you sent an email that I have posted in its entirety below. > START Michael, Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. Respectfully, Elad > END Please just stop it Elad. Now I still think it was wrong of rfg to use that word, but it is not at all the same thing in my eyes. - Cynthia On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen > wrote: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301.html These are all complete lies only because I found out who are the real people behind "The Spamhaus Project" You can see how he is calling me there Everything there are lies and fake, the "source" for the fake media report is a member of "The Spamhaus Project" and also an employee of a direct competitor (that enjoyed from that fake media report) of a company which used the netblock, and the "source" is also the owner of that criminal twitter account: https://twitter.com/UnderTheBreach , he is a master of cyber influence operations according to his own words in his criminal twitter account and also a member of your cyber-security community. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:14 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, please send me an archive link to the specific email on a RIPE/RIPE NCC mailing list where RFG called you a rude name. - Cynthia On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen > wrote: He called me with antisemitic names many times and on many working groups and you said nothing, you claim not to see his messages, but you clearly saw all of my messages and you are monitoring me pretty well. I'm sorry but I don't believe you, specially when you are attacking me personally so heavily with distorting the facts. You clearly so the word coconut - so you also saw what I shared on the same post that he wrote on other groups of people and that he was called a racist and an antisemitic - but you decided to ignore this as well, so you didn't read my whole post - you read only the word 'coconut' and you decided to jump in ? Cynthia, please spread your lies somewhere else. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:05 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, first of all, I am not an employee or in any way related to Spamhaus, and I doubt many of the people you have suggested are part of it have anything to do with it either. And because I have things to do that are not spending my entire days on RIPE mailing lists I guess I missed RFG calling you names, but I will assure you that if I was on those discussions I would call him out if he called you a "coconut" or similar. Also just because someone has called you names on mailing lists doesn't mean you get to call them names on mailing lists. - Cynthia On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen > wrote: Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re -------------- next part -------------- An HTML attachment was scrubbed... URL: From campbell at inca.ie Mon Apr 27 15:47:34 2020 From: campbell at inca.ie (Ed Campbell) Date: Mon, 27 Apr 2020 14:47:34 +0100 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: <20200427104032.GU2680@cilantro.c4inet.net> <385A998E-586A-46CA-87EC-F8F3410836AB@nomical.com> Message-ID: <1CA4776E-0A2F-4118-87C2-87A40FA6D279@inca.ie> All, This guy doesn?t know how to shut up. I would not normally do this but he is harassing me directly ?off-list? and ?off-topic?. The unprofessional approach he has taken to his responses should be enough to turn anyone away from him but he is now harassing me when asked not to. I have made an official complaint against him and will let the NCC deal with him. Kind regards, Ed On 27 Apr 2020, at 14:43, Elad Cohen wrote: Chris, This wasn't my conversation, this was my response to an attack on me. Take your fake messages off the list. Respectfully, Elad From: Chris Lawrence > Sent: Monday, April 27, 2020 3:44 PM To: Elad Cohen >; Cynthia Revstr?m >; members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad Enough now this is beyond a joke.. Please take your conversations off the list. Regards Chris Chris Lawrence? Senior Solutions Architect +44?344?384?3000 +44?7775?871094 nomical.com Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE This email and any attachments are intended for the named recipient only. Its unauthorised use, distribution, disclosure, storage or copying is not permitted. If you have received it in error, please destroy all copies and notify the sender. In messages of a non-business nature, the views and opinions expressed are the author's own and do not necessarily reflect those of the organisation from which it is sent. All emails may be subject to monitoring. Nomical Ltd - Registered in England No: 06035958, VAT Reg No: 900363074, Registered Office: Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE From: members-discuss > on behalf of Elad Cohen > Date: Monday, 27 April 2020 at 13:43 To: Cynthia Revstr?m >, "members-discuss at ripe.net " > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails This is amazing how the illegal anonymous "The Spamhaus Project" members keep twisting the facts. Cynthia, Zero evidence was provided, not even a single proof, but still you claim "lots of evidence" I didn't say that anyone is part of "The Spamhaus Project" because disagree with me, I said that anyone is part of the illegal anonymous organization "The Spamhaus Project" because he is part of the illegal anonymous organization "The Spamhaus Project" - see how much you are personally targeting me - see how much you are protecting your sick friend RFG. Please don't interpret me - coconut means coconut - RFG is a coconut by anyone that knows him personally. Here is what your sick friend wrote: https://imgur.com/AcmgwEX (his opinion on all Dutch people as a whole - "Dutch are any more inclined toward cybercrime") https://imgur.com/WUZvdNJ (his opinion on all Colombian Network Operators usage of the internet as a whole - "Undoubtedly drug smuggling over HTTP") https://imgur.com/a/1ULfVEC (his opinion on the City of Chicago including all of its citizens as a whole - "American city most known for its high ideals and consistantely ethical behavior, Chicago") https://imgur.com/AQCmZlk (RFG being identified as racist in Nanog) https://imgur.com/a/Rzrbxkz (RFG being identified as antisemitic in Nanog) RFG called me in two names that one of them you wrote, you can keep with your lies and to defend a racist and an antisemitic person - but there is something which is called context, you can see in the first link above that RFG quoted Shakespeare regarding the Netherlands, when he called me in the name that you mentioned he did it after not providing not even a single proof against me and he specially used that name - which also in Shakespeare being referred to jews - you are defending a person which is a racist and an antisemitic according to all the above links. Respectfully, Elad From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:50 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hi Elad, There are 3 major differences I see here, 1. rfg presents lots of evidence that you would have been involved in shady things (I am not sure if they are true and frankly I don't have time currently to look at all of the documents) Meanwhile you are saying that people are part of "The illegal anonymous Spamhaus Project" just because they disagree with you, and as you have said that I am involved in Spamhaus, I would like for you to give me any proof that I am involved with spamhaus in any way (which I am not). 2. rfg called you a "crook", which means dishonest or illegal, which would be true if the things rfg stated are in fact true. Meanwhile you called rfg a "coconut" which can't be anything other than an insult referring to you thinking he is dumb. 3. rfg called you a "crook" once in a long email after describing why he thinks you are a "crook", meanwhile you sent an email that I have posted in its entirety below. > START Michael, Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. Respectfully, Elad > END Please just stop it Elad. Now I still think it was wrong of rfg to use that word, but it is not at all the same thing in my eyes. - Cynthia On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen > wrote: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301.html These are all complete lies only because I found out who are the real people behind "The Spamhaus Project" You can see how he is calling me there Everything there are lies and fake, the "source" for the fake media report is a member of "The Spamhaus Project" and also an employee of a direct competitor (that enjoyed from that fake media report) of a company which used the netblock, and the "source" is also the owner of that criminal twitter account:https://twitter.com/UnderTheBreach , he is a master of cyber influence operations according to his own words in his criminal twitter account and also a member of your cyber-security community. Respectfully, Elad From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:14 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, please send me an archive link to the specific email on a RIPE/RIPE NCC mailing list where RFG called you a rude name. - Cynthia On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen > wrote: He called me with antisemitic names many times and on many working groups and you said nothing, you claim not to see his messages, but you clearly saw all of my messages and you are monitoring me pretty well. I'm sorry but I don't believe you, specially when you are attacking me personally so heavily with distorting the facts. You clearly so the word coconut - so you also saw what I shared on the same post that he wrote on other groups of people and that he was called a racist and an antisemitic - but you decided to ignore this as well, so you didn't read my whole post - you read only the word 'coconut' and you decided to jump in ? Cynthia, please spread your lies somewhere else. Respectfully, Elad From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:05 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, first of all, I am not an employee or in any way related to Spamhaus, and I doubt many of the people you have suggested are part of it have anything to do with it either. And because I have things to do that are not spending my entire days on RIPE mailing lists I guess I missed RFG calling you names, but I will assure you that if I was on those discussions I would call him out if he called you a "coconut" or similar. Also just because someone has called you names on mailing lists doesn't mean you get to call them names on mailing lists. - Cynthia On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen > wrote: Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1442 bytes Desc: not available URL: From elad at netstyle.io Mon Apr 27 15:48:57 2020 From: elad at netstyle.io (Elad Cohen) Date: Mon, 27 Apr 2020 13:48:57 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails Message-ID: Ed is lying, I'm not harassing him or anyone else off the list, Ed is the one keep emailing me directly when I asked him to stop doing it. Respectfully, Elad ________________________________ From: Ed Campbell Sent: Monday, April 27, 2020 4:47 PM To: Elad Cohen Cc: Chris Lawrence; Cynthia Revstr?m; members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails All, This guy doesn?t know how to shut up. I would not normally do this but he is harassing me directly ?off-list? and ?off-topic?. The unprofessional approach he has taken to his responses should be enough to turn anyone away from him but he is now harassing me when asked not to. I have made an official complaint against him and will let the NCC deal with him. Kind regards, Ed On 27 Apr 2020, at 14:43, Elad Cohen > wrote: Chris, This wasn't my conversation, this was my response to an attack on me. Take your fake messages off the list. Respectfully, Elad ________________________________ From: Chris Lawrence > Sent: Monday, April 27, 2020 3:44 PM To: Elad Cohen >; Cynthia Revstr?m >; members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad Enough now this is beyond a joke.. Please take your conversations off the list. Regards Chris Chris Lawrence? Senior Solutions Architect +44 344 384 3000 +44 7775 871094 nomical.com Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE This email and any attachments are intended for the named recipient only. Its unauthorised use, distribution, disclosure, storage or copying is not permitted. If you have received it in error, please destroy all copies and notify the sender. In messages of a non-business nature, the views and opinions expressed are the author's own and do not necessarily reflect those of the organisation from which it is sent. All emails may be subject to monitoring. Nomical Ltd - Registered in England No: 06035958, VAT Reg No: 900363074, Registered Office: Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE From: members-discuss > on behalf of Elad Cohen > Date: Monday, 27 April 2020 at 13:43 To: Cynthia Revstr?m >, "members-discuss at ripe.net" > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails This is amazing how the illegal anonymous "The Spamhaus Project" members keep twisting the facts. Cynthia, Zero evidence was provided, not even a single proof, but still you claim "lots of evidence" I didn't say that anyone is part of "The Spamhaus Project" because disagree with me, I said that anyone is part of the illegal anonymous organization "The Spamhaus Project" because he is part of the illegal anonymous organization "The Spamhaus Project" - see how much you are personally targeting me - see how much you are protecting your sick friend RFG. Please don't interpret me - coconut means coconut - RFG is a coconut by anyone that knows him personally. Here is what your sick friend wrote: https://imgur.com/AcmgwEX (his opinion on all Dutch people as a whole - "Dutch are any more inclined toward cybercrime") https://imgur.com/WUZvdNJ (his opinion on all Colombian Network Operators usage of the internet as a whole - "Undoubtedly drug smuggling over HTTP") https://imgur.com/a/1ULfVEC (his opinion on the City of Chicago including all of its citizens as a whole - "American city most known for its high ideals and consistantely ethical behavior, Chicago") https://imgur.com/AQCmZlk (RFG being identified as racist in Nanog) https://imgur.com/a/Rzrbxkz (RFG being identified as antisemitic in Nanog) RFG called me in two names that one of them you wrote, you can keep with your lies and to defend a racist and an antisemitic person - but there is something which is called context, you can see in the first link above that RFG quoted Shakespeare regarding the Netherlands, when he called me in the name that you mentioned he did it after not providing not even a single proof against me and he specially used that name - which also in Shakespeare being referred to jews - you are defending a person which is a racist and an antisemitic according to all the above links. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:50 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hi Elad, There are 3 major differences I see here, 1. rfg presents lots of evidence that you would have been involved in shady things (I am not sure if they are true and frankly I don't have time currently to look at all of the documents) Meanwhile you are saying that people are part of "The illegal anonymous Spamhaus Project" just because they disagree with you, and as you have said that I am involved in Spamhaus, I would like for you to give me any proof that I am involved with spamhaus in any way (which I am not). 2. rfg called you a "crook", which means dishonest or illegal, which would be true if the things rfg stated are in fact true. Meanwhile you called rfg a "coconut" which can't be anything other than an insult referring to you thinking he is dumb. 3. rfg called you a "crook" once in a long email after describing why he thinks you are a "crook", meanwhile you sent an email that I have posted in its entirety below. > START Michael, Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. Respectfully, Elad > END Please just stop it Elad. Now I still think it was wrong of rfg to use that word, but it is not at all the same thing in my eyes. - Cynthia On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen > wrote: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301.html These are all complete lies only because I found out who are the real people behind "The Spamhaus Project" You can see how he is calling me there Everything there are lies and fake, the "source" for the fake media report is a member of "The Spamhaus Project" and also an employee of a direct competitor (that enjoyed from that fake media report) of a company which used the netblock, and the "source" is also the owner of that criminal twitter account:https://twitter.com/UnderTheBreach , he is a master of cyber influence operations according to his own words in his criminal twitter account and also a member of your cyber-security community. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:14 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, please send me an archive link to the specific email on a RIPE/RIPE NCC mailing list where RFG called you a rude name. - Cynthia On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen > wrote: He called me with antisemitic names many times and on many working groups and you said nothing, you claim not to see his messages, but you clearly saw all of my messages and you are monitoring me pretty well. I'm sorry but I don't believe you, specially when you are attacking me personally so heavily with distorting the facts. You clearly so the word coconut - so you also saw what I shared on the same post that he wrote on other groups of people and that he was called a racist and an antisemitic - but you decided to ignore this as well, so you didn't read my whole post - you read only the word 'coconut' and you decided to jump in ? Cynthia, please spread your lies somewhere else. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:05 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, first of all, I am not an employee or in any way related to Spamhaus, and I doubt many of the people you have suggested are part of it have anything to do with it either. And because I have things to do that are not spending my entire days on RIPE mailing lists I guess I missed RFG calling you names, but I will assure you that if I was on those discussions I would call him out if he called you a "coconut" or similar. Also just because someone has called you names on mailing lists doesn't mean you get to call them names on mailing lists. - Cynthia On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen > wrote: Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola at newcomm.it Mon Apr 27 15:51:53 2020 From: nicola at newcomm.it (Nicola Zanotelli - NEW) Date: Mon, 27 Apr 2020 15:51:53 +0200 (CEST) Subject: [members-discuss] R: UNSUBSCRIBE In-Reply-To: <3be35972-1023-26a5-106d-a8a5f37e9a86@fastnet.it> References: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> <3be35972-1023-26a5-106d-a8a5f37e9a86@fastnet.it> Message-ID: <001101d61c9b$02129850$0637c8f0$@newcomm.it> UNSUBSCRIBE Da: members-discuss Per conto di Andrea Pieralisi Inviato: luned? 27 aprile 2020 15:40 A: members-discuss at ripe.net Oggetto: Re: [members-discuss] UNSUBSCRIBE -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Mon Apr 27 15:52:37 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Mon, 27 Apr 2020 13:52:37 +0000 Subject: [members-discuss] Regarding Elad Cohen's nomination and emails In-Reply-To: References: Message-ID: Elad, PLEASE, for the love of sanity, STOP responding. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 27 April 2020 14:49 To: Ed Campbell Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Ed is lying, I'm not harassing him or anyone else off the list, Ed is the one keep emailing me directly when I asked him to stop doing it. Respectfully, Elad ________________________________ From: Ed Campbell Sent: Monday, April 27, 2020 4:47 PM To: Elad Cohen Cc: Chris Lawrence; Cynthia Revstr?m; members-discuss at ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails All, This guy doesn?t know how to shut up. I would not normally do this but he is harassing me directly ?off-list? and ?off-topic?. The unprofessional approach he has taken to his responses should be enough to turn anyone away from him but he is now harassing me when asked not to. I have made an official complaint against him and will let the NCC deal with him. Kind regards, Ed On 27 Apr 2020, at 14:43, Elad Cohen > wrote: Chris, This wasn't my conversation, this was my response to an attack on me. Take your fake messages off the list. Respectfully, Elad ________________________________ From: Chris Lawrence > Sent: Monday, April 27, 2020 3:44 PM To: Elad Cohen >; Cynthia Revstr?m >; members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad Enough now this is beyond a joke.. Please take your conversations off the list. Regards Chris Chris Lawrence? Senior Solutions Architect +44 344 384 3000 +44 7775 871094 nomical.com Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE This email and any attachments are intended for the named recipient only. Its unauthorised use, distribution, disclosure, storage or copying is not permitted. If you have received it in error, please destroy all copies and notify the sender. In messages of a non-business nature, the views and opinions expressed are the author's own and do not necessarily reflect those of the organisation from which it is sent. All emails may be subject to monitoring. Nomical Ltd - Registered in England No: 06035958, VAT Reg No: 900363074, Registered Office: Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE From: members-discuss > on behalf of Elad Cohen > Date: Monday, 27 April 2020 at 13:43 To: Cynthia Revstr?m >, "members-discuss at ripe.net" > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails This is amazing how the illegal anonymous "The Spamhaus Project" members keep twisting the facts. Cynthia, Zero evidence was provided, not even a single proof, but still you claim "lots of evidence" I didn't say that anyone is part of "The Spamhaus Project" because disagree with me, I said that anyone is part of the illegal anonymous organization "The Spamhaus Project" because he is part of the illegal anonymous organization "The Spamhaus Project" - see how much you are personally targeting me - see how much you are protecting your sick friend RFG. Please don't interpret me - coconut means coconut - RFG is a coconut by anyone that knows him personally. Here is what your sick friend wrote: https://imgur.com/AcmgwEX (his opinion on all Dutch people as a whole - "Dutch are any more inclined toward cybercrime") https://imgur.com/WUZvdNJ (his opinion on all Colombian Network Operators usage of the internet as a whole - "Undoubtedly drug smuggling over HTTP") https://imgur.com/a/1ULfVEC (his opinion on the City of Chicago including all of its citizens as a whole - "American city most known for its high ideals and consistantely ethical behavior, Chicago") https://imgur.com/AQCmZlk (RFG being identified as racist in Nanog) https://imgur.com/a/Rzrbxkz (RFG being identified as antisemitic in Nanog) RFG called me in two names that one of them you wrote, you can keep with your lies and to defend a racist and an antisemitic person - but there is something which is called context, you can see in the first link above that RFG quoted Shakespeare regarding the Netherlands, when he called me in the name that you mentioned he did it after not providing not even a single proof against me and he specially used that name - which also in Shakespeare being referred to jews - you are defending a person which is a racist and an antisemitic according to all the above links. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:50 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hi Elad, There are 3 major differences I see here, 1. rfg presents lots of evidence that you would have been involved in shady things (I am not sure if they are true and frankly I don't have time currently to look at all of the documents) Meanwhile you are saying that people are part of "The illegal anonymous Spamhaus Project" just because they disagree with you, and as you have said that I am involved in Spamhaus, I would like for you to give me any proof that I am involved with spamhaus in any way (which I am not). 2. rfg called you a "crook", which means dishonest or illegal, which would be true if the things rfg stated are in fact true. Meanwhile you called rfg a "coconut" which can't be anything other than an insult referring to you thinking he is dumb. 3. rfg called you a "crook" once in a long email after describing why he thinks you are a "crook", meanwhile you sent an email that I have posted in its entirety below. > START Michael, Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. Respectfully, Elad > END Please just stop it Elad. Now I still think it was wrong of rfg to use that word, but it is not at all the same thing in my eyes. - Cynthia On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen > wrote: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301.html These are all complete lies only because I found out who are the real people behind "The Spamhaus Project" You can see how he is calling me there Everything there are lies and fake, the "source" for the fake media report is a member of "The Spamhaus Project" and also an employee of a direct competitor (that enjoyed from that fake media report) of a company which used the netblock, and the "source" is also the owner of that criminal twitter account:https://twitter.com/UnderTheBreach , he is a master of cyber influence operations according to his own words in his criminal twitter account and also a member of your cyber-security community. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:14 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, please send me an archive link to the specific email on a RIPE/RIPE NCC mailing list where RFG called you a rude name. - Cynthia On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen > wrote: He called me with antisemitic names many times and on many working groups and you said nothing, you claim not to see his messages, but you clearly saw all of my messages and you are monitoring me pretty well. I'm sorry but I don't believe you, specially when you are attacking me personally so heavily with distorting the facts. You clearly so the word coconut - so you also saw what I shared on the same post that he wrote on other groups of people and that he was called a racist and an antisemitic - but you decided to ignore this as well, so you didn't read my whole post - you read only the word 'coconut' and you decided to jump in ? Cynthia, please spread your lies somewhere else. Respectfully, Elad ________________________________ From: Cynthia Revstr?m > Sent: Monday, April 27, 2020 2:05 PM To: Elad Cohen > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, first of all, I am not an employee or in any way related to Spamhaus, and I doubt many of the people you have suggested are part of it have anything to do with it either. And because I have things to do that are not spending my entire days on RIPE mailing lists I guess I missed RFG calling you names, but I will assure you that if I was on those discussions I would call him out if he called you a "coconut" or similar. Also just because someone has called you names on mailing lists doesn't mean you get to call them names on mailing lists. - Cynthia On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen > wrote: Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss > on behalf of Cynthia Revstr?m > Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] > Cc: members-discuss at ripe.net > Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] > wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss at ripe.net >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From Thierry.VANEYCKE at viparis.com Mon Apr 27 16:03:01 2020 From: Thierry.VANEYCKE at viparis.com (VANEYCKE Thierry) Date: Mon, 27 Apr 2020 14:03:01 +0000 Subject: [members-discuss] R: UNSUBSCRIBE In-Reply-To: <001101d61c9b$02129850$0637c8f0$@newcomm.it> References: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> <3be35972-1023-26a5-106d-a8a5f37e9a86@fastnet.it> <001101d61c9b$02129850$0637c8f0$@newcomm.it> Message-ID: UNSUBSCRIBE De : members-discuss De la part de Nicola Zanotelli - NEW Envoy? : lundi 27 avril 2020 15:52 ? : members-discuss at ripe.net Objet : [members-discuss] R: UNSUBSCRIBE UNSUBSCRIBE Da: members-discuss > Per conto di Andrea Pieralisi Inviato: luned? 27 aprile 2020 15:40 A: members-discuss at ripe.net Oggetto: Re: [members-discuss] UNSUBSCRIBE This e-mail and/or attachment(s) is (are) confidential and may be legally protected. This message is addressed to the intended recipient only. If you are not the intended recipient of the message, please notify the sender immediately. Its contents do not constitute a commitment by the sender's company except where provided for in a written and signed agreement between you and sender's company. Any disclosure, use or dissemination, either in whole or in partial, shall be prior authorized by the sender's company by written and signed agreement. E-mail and/or attachment(s) cannot be guaranteed to be secured or error-free as information can be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender's company has taken all reasonable precautions to ensure that any attachment to this message does not contain a virus. However, the sender's company (and not any of its Officers, Directors, Employees or Agents) cannot be held liable for any damages resulting from or linked to the existence of a virus. You are therefore strongly advised to carry out all your own anti-virus checks before opening any and all attachments to this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at snell.es Mon Apr 27 16:05:07 2020 From: info at snell.es (Info Snell) Date: Mon, 27 Apr 2020 16:05:07 +0200 Subject: [members-discuss] UNSUBSCRIBE In-Reply-To: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> References: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> Message-ID: UNSUBSCRIBE El lun., 27 abr. 2020 a las 13:19, David Simmons (< david.simmons at elite.net.uk>) escribi?: > UNSUBSCRIBE > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/info%40snell.es > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angel at alojalia.com Mon Apr 27 16:13:01 2020 From: angel at alojalia.com (=?UTF-8?Q?=c3=81ngel_Mart=c3=adnez?=) Date: Mon, 27 Apr 2020 16:13:01 +0200 Subject: [members-discuss] UNSUBSCRIBE In-Reply-To: <3be35972-1023-26a5-106d-a8a5f37e9a86@fastnet.it> References: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> <3be35972-1023-26a5-106d-a8a5f37e9a86@fastnet.it> Message-ID: <6040a0ae-b433-4df9-154f-644437e4b374@alojalia.com> UNSUBSCRIBE El 27/04/2020 a las 15:40, Andrea Pieralisi escribi?: > > UNSUBSCRIBE > > Il 27/04/2020 15:34, Enis MURATI ha scritto: >> >> UNSUBSCRIBE >> >> Me nderime/Regards >> >> *Enis Murati* >> >> *From:*members-discuss *On Behalf >> Of *David Simmons >> *Sent:* Monday, April 27, 2020 1:19 PM >> *To:* members-discuss at ripe.net >> *Subject:* [members-discuss] UNSUBSCRIBE >> >> UNSUBSCRIBE >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/anpier%40fastnet.it > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/angel%40alojalia.com From mail at mys.co.uk Mon Apr 27 16:19:04 2020 From: mail at mys.co.uk (MYS Ltd) Date: Mon, 27 Apr 2020 15:19:04 +0100 Subject: [members-discuss] UNSUBSCRIBE In-Reply-To: <6040a0ae-b433-4df9-154f-644437e4b374@alojalia.com> References: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> <3be35972-1023-26a5-106d-a8a5f37e9a86@fastnet.it> <6040a0ae-b433-4df9-154f-644437e4b374@alojalia.com> Message-ID: UNSUBSCRIBE From: members-discuss on behalf of ?ngel Mart?nez Organization: Alojalia Cloud SLU Reply-To: Date: Monday, 27 April 2020 at 15:13 To: "members-discuss at ripe.net" Subject: Re: [members-discuss] UNSUBSCRIBE UNSUBSCRIBE El 27/04/2020 a las 15:40, Andrea Pieralisi escribi?: > > UNSUBSCRIBE > > Il 27/04/2020 15:34, Enis MURATI ha scritto: >> >> UNSUBSCRIBE >> >> Me nderime/Regards >> >> *Enis Murati* >> >> *From:*members-discuss *On Behalf >> Of *David Simmons >> *Sent:* Monday, April 27, 2020 1:19 PM >> *To:* members-discuss at ripe.net >> *Subject:* [members-discuss] UNSUBSCRIBE >> >> UNSUBSCRIBE >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> >> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/anpier%40f >> astnet.it > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/angel%40alojalia.com _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/mail%40mys.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bledi.Vako at intesasanpaolobank.al Mon Apr 27 16:19:25 2020 From: Bledi.Vako at intesasanpaolobank.al (Bledi Vako) Date: Mon, 27 Apr 2020 14:19:25 +0000 Subject: [members-discuss] UNSUBSCRIBE In-Reply-To: <6040a0ae-b433-4df9-154f-644437e4b374@alojalia.com> References: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> <3be35972-1023-26a5-106d-a8a5f37e9a86@fastnet.it> <6040a0ae-b433-4df9-154f-644437e4b374@alojalia.com> Message-ID: <972BECC37E766E4DBBCBBB78990D3F35013C79A9B9@Exch-MBX11.aba.net> Classification: Normal UNSUBSCRIBE This email has been marked as NORMAL by Bledi Vako on Monday, April 27, 2020. -----Original Message----- From: members-discuss On Behalf Of ?ngel Mart?nez Sent: Monday, April 27, 2020 16:13 To: members-discuss at ripe.net Subject: Re: [members-discuss] UNSUBSCRIBE UNSUBSCRIBE El 27/04/2020 a las 15:40, Andrea Pieralisi escribi?: > > UNSUBSCRIBE > > Il 27/04/2020 15:34, Enis MURATI ha scritto: >> >> UNSUBSCRIBE >> >> Me nderime/Regards >> >> *Enis Murati* >> >> *From:*members-discuss *On Behalf >> Of *David Simmons >> *Sent:* Monday, April 27, 2020 1:19 PM >> *To:* members-discuss at ripe.net >> *Subject:* [members-discuss] UNSUBSCRIBE >> >> UNSUBSCRIBE >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> BLOCKEDlists[.]ripe[.]net/mailman/listinfo/members-discussBLOCKED >> Unsubscribe:BLOCKEDlists[.]ripe[.]net/mailman/options/members-discuss >> /anpier%40fastnet[.]itBLOCKED > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > BLOCKEDlists[.]ripe[.]net/mailman/listinfo/members-discussBLOCKED > Unsubscribe: > BLOCKEDlists[.]ripe[.]net/mailman/options/members-discuss/angel%40aloj > alia[.]comBLOCKED _______________________________________________ members-discuss mailing list members-discuss at ripe.net BLOCKEDlists[.]ripe[.]net/mailman/listinfo/members-discussBLOCKED Unsubscribe: BLOCKEDlists[.]ripe[.]net/mailman/options/members-discuss/bledi[.]vako%40intesasanpaolobank[.]alBLOCKED Ky e-mail dhe ?do dokument bashkangjitur jan? konfidencial? dhe t? destinuar p?r t?u p?rdorur vet?m nga individi ose entiteti t? cilit i drejtohen. N?se e keni marr? gabimisht k?t? e-mail, ju lutemi njoftoni menj?her? d?rguesin dhe fshini nga kompjuteri ?do material n? p?rmbajtjen e tij. N?se nuk jeni marr?si i synuar, jeni t? njoftuar se kopjimi, shp?rndarja ose nd?rmarrja e ?do lloj veprimi n? lidhje me p?rmbajtjen e k?tij informacioni ?sht? rrept?sisht e ndaluar. This e-mail and any files attached to it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please notify the sender and delete from your computer any material contained in it immediately. If you are not the intended recipient, you are notified that copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. [http://intesasanpaolobank.com.al/graphics/emailfooter.png] From adr at comenersol.com Mon Apr 27 16:23:02 2020 From: adr at comenersol.com (Comenersol) Date: Mon, 27 Apr 2020 16:23:02 +0200 Subject: [members-discuss] RV: UNSUBSCRIBE In-Reply-To: <6040a0ae-b433-4df9-154f-644437e4b374@alojalia.com> References: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> <3be35972-1023-26a5-106d-a8a5f37e9a86@fastnet.it> <6040a0ae-b433-4df9-154f-644437e4b374@alojalia.com> Message-ID: <06a901d61c9f$5f9a64e0$1ecf2ea0$@comenersol.com> UNSUBSCRIBE, PLEASE REGARDS El 27/04/2020 a las 15:40, Andrea Pieralisi escribi?: > > UNSUBSCRIBE > > Il 27/04/2020 15:34, Enis MURATI ha scritto: >> >> UNSUBSCRIBE >> >> Me nderime/Regards >> >> *Enis Murati* >> >> *From:*members-discuss *On Behalf >> Of *David Simmons >> *Sent:* Monday, April 27, 2020 1:19 PM >> *To:* members-discuss at ripe.net >> *Subject:* [members-discuss] UNSUBSCRIBE >> >> UNSUBSCRIBE >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/an >> pier%40fastnet.it > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/angel%40alojali > a.com _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/adr%40comenersol.com From crodler at ensinca.net Mon Apr 27 16:41:49 2020 From: crodler at ensinca.net (Christian Rodler) Date: Mon, 27 Apr 2020 16:41:49 +0200 Subject: [members-discuss] ban4flood Message-ID: <307e11dd-713d-15fd-61cd-96f964cdf555@ensinca.net> Before most of us unsubscribe from this list: Would be nice if the "responsible" of this mailing list could find a way to ban a member for lets say one week if? >x% of subscibers complain about (off-topics- coconuts or whatever). I never thought membes-discuss mailing list == Kindergarden Best regards, Christian Rodler -- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus From sharififar at gmail.com Mon Apr 27 16:44:02 2020 From: sharififar at gmail.com (Massoud Sharififar) Date: Mon, 27 Apr 2020 10:44:02 -0400 Subject: [members-discuss] UNSUBSCRIBE In-Reply-To: <972BECC37E766E4DBBCBBB78990D3F35013C79A9B9@Exch-MBX11.aba.net> References: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> <3be35972-1023-26a5-106d-a8a5f37e9a86@fastnet.it> <6040a0ae-b433-4df9-154f-644437e4b374@alojalia.com> <972BECC37E766E4DBBCBBB78990D3F35013C79A9B9@Exch-MBX11.aba.net> Message-ID: Classification: Normal UNSUBSCRIBE On April 27, 2020 at 10:25:17, Bledi Vako (bledi.vako at intesasanpaolobank.al) wrote: Classification: Normal UNSUBSCRIBE -------------- next part -------------- An HTML attachment was scrubbed... URL: From lircontrib at orion.it Mon Apr 27 17:16:01 2020 From: lircontrib at orion.it (nouvelle) Date: Mon, 27 Apr 2020 17:16:01 +0200 Subject: [members-discuss] ban4flood In-Reply-To: <307e11dd-713d-15fd-61cd-96f964cdf555@ensinca.net> References: <307e11dd-713d-15fd-61cd-96f964cdf555@ensinca.net> Message-ID: <20200427151601.GA10140@dante.orion.it> And in case this very good advice is not followed, and because this is now beyond: *) ludicrous *) annoying *) ridiculous *) ... and taking place on a seemingly professional list - whoever uses procmail for presorting/filtering its email in a maildir mailbox, can use this rule: :0 * 1^0 ^List-Id:.*members-discuss.ripe.net $DEFAULT/.ZY-lists.members-discuss-ripe/ to silence this horror. I set the output to a separate folder but, at this point, something like $DEFAULT/.Spam or /dev/null is equally or more appropriate. Cheers, Mon, Apr 27, 2020 at 04:41:49PM +0200, Christian Rodler wrote: > Before most of us unsubscribe from this list: > > Would be nice if the "responsible" of this mailing list could find a > way to ban a member for lets say one week if? >x% of subscibers > complain about (off-topics- coconuts or whatever). > > I never thought membes-discuss mailing list == Kindergarden > > > Best regards, > > Christian Rodler > > > -- > El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. > https://www.avast.com/antivirus > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/lircontrib%40orion.it > From daniele at yottanet.it Mon Apr 27 17:26:19 2020 From: daniele at yottanet.it (Daniele Ferrara) Date: Mon, 27 Apr 2020 17:26:19 +0200 Subject: [members-discuss] UNSUBSCRIBE In-Reply-To: <6040a0ae-b433-4df9-154f-644437e4b374@alojalia.com> References: <48AA9521-837C-4AA3-83B3-068ECC9335F1@contoso.com> <3be35972-1023-26a5-106d-a8a5f37e9a86@fastnet.it> <6040a0ae-b433-4df9-154f-644437e4b374@alojalia.com> Message-ID: <01a801d61ca8$33c63700$9b52a500$@it> ------------------------------ Daniele Ferrara ? CEO Via nuova chiunzi,106 - 84010 - Maiori(SA) Tel 089/8423650; Fax 089/8422112 P.IVA 05500240659 ? REA SA450683 daniele at yottanet.it ? http://www.yottanet.it Ai sensi del D.lgs n.196 del 30.06.03 (Codice Privacy) si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il messaggio Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie This message, for the D.lgs n.196 / 30.06.03 (Privacy Code), may contain confidential and/or privileged information.If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein.If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -----Original Message----- From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of ?ngel Mart?nez Sent: luned? 27 aprile 2020 16:13 To: members-discuss at ripe.net Subject: Re: [members-discuss] UNSUBSCRIBE UNSUBSCRIBE El 27/04/2020 a las 15:40, Andrea Pieralisi escribi?: > > UNSUBSCRIBE > > Il 27/04/2020 15:34, Enis MURATI ha scritto: >> >> UNSUBSCRIBE >> >> Me nderime/Regards >> >> *Enis Murati* >> >> *From:*members-discuss *On Behalf >> Of *David Simmons >> *Sent:* Monday, April 27, 2020 1:19 PM >> *To:* members-discuss at ripe.net >> *Subject:* [members-discuss] UNSUBSCRIBE >> >> UNSUBSCRIBE >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/anpier%40fastnet.it > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/angel%40alojalia.com _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/daniele%40yottanet.it From exec-board at ripe.net Mon Apr 27 17:27:14 2020 From: exec-board at ripe.net (=?UTF-8?Q?Piotr_Strzy=c5=bcewski?=) Date: Mon, 27 Apr 2020 17:27:14 +0200 Subject: [members-discuss] Mailing List Purpose and Request for Consideration Message-ID: <9ea844b8-a898-1c78-8bff-2062b2fbc70e@ripe.net> Dear all, I would like to remind you of the purpose of this list. It is to allow members to discuss matters of importance relating to their membership of the RIPE NCC. All other topics should be considered not relevant for this list. The Board is always pleased to see good discussion on the list, and we realise this can become heated at times. However, thousands of members are subscribed to the list and receive these emails. Therefore, I ask you to be considerate of your fellow members in terms of both content and frequency of mails. For those who wish to unsubscribe, please read the information available at: https://www.ripe.net/participate/member-support/membership-mailing-lists/subscribing-to-members-discuss Kind regards, Piotr Strzy?ewski RIPE NCC Executive Board Secretary From elad at netstyle.io Thu Apr 30 22:30:48 2020 From: elad at netstyle.io (Elad Cohen) Date: Thu, 30 Apr 2020 20:30:48 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Message-ID: Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From munir at aeserver.com Thu Apr 30 22:34:26 2020 From: munir at aeserver.com (Munir Badr) Date: Fri, 1 May 2020 00:34:26 +0400 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: Message-ID: Let the fun begin again!!! On Fri, 1 May 2020 at 00:31 Elad Cohen wrote: > Hello Ripe Members! > > 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. > > 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. > > 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. > > > 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) > > 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. > > > The Process: > > 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. > > In the new tracking ip packet there will be a new transport layer protocol > (tracking protocol) with the following fields: > AS number of source BGP router in clear text > AS number of source BGP router encrypted with the private key of the > source BGP router > > 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': > If 'off' then the destination BGP router will drop that 'tracking ip > packet' > > If 'on' then the destination BGP router will decrypt the 'encrypted AS > number' with the public key of the specific AS number > and after decryption the AS number need to be the result: > if not then to drop the tracking ip packet and the original ip packet > related to it > 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) > > > 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. > > 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. > > > > More Aspects: > > - 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. > - 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. > - Each BGP router will have all the public keys (of all the ASN's) locally. > - 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. > > > > 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'): > > - 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) > - 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. > - 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. > - 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). > - 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. > - 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. > > - 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. > - 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. > > > > 'Check tracking flag' in BGP Routers: > > - 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. > - The ICANN backend infrastructure through the session with the BGP router > - will be able to set the boolean value of the 'Check tracking flag'. > - 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. > - 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' > - 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. > - 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. > > > > Automatic preventation of IoT botnet infections: > > - 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. > - 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. > - 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. > - 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. > > > > Automatic prevention of botnet C&C ip addresses: > > - Botnets C&C are also a problem in the internet. > - 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. > - 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. > > > Respectfully, > Elad > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/munir%40aeserver.com > -- *MUNIR BADR* Book A Call: Click here Sales Hotline: *800 123 123* | Intl: +971 4 2493030 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bora.ismen at nimbevo.com Thu Apr 30 22:38:10 2020 From: bora.ismen at nimbevo.com (Bora Ismen) Date: Thu, 30 Apr 2020 21:38:10 +0100 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: Message-ID: <8a2556imdci2jftp7bqaqcgb.1588279038367@email.android.com> Is there a way to unsubscribe from individual topics? I don't want to be part of this fun... -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Thu Apr 30 22:39:03 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Thu, 30 Apr 2020 20:39:03 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: Message-ID: <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn..... From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Thu Apr 30 22:41:56 2020 From: elad at netstyle.io (Elad Cohen) Date: Thu, 30 Apr 2020 20:41:56 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> References: , <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> Message-ID: Stuart, 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. Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen ; members-discuss at ripe.net Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn?.. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Thu Apr 30 22:43:21 2020 From: elad at netstyle.io (Elad Cohen) Date: Thu, 30 Apr 2020 20:43:21 +0000 Subject: [members-discuss] Fw: You have my vote! In-Reply-To: <171ccd37798.27df.56e98b263721135ab28082bde6596530@infinitytelecom.ro> References: <171ccd37798.27df.56e98b263721135ab28082bde6596530@infinitytelecom.ro> Message-ID: Thank you Gabriel. Respectfully, Elad ________________________________________ From: Gabriel VOITIS Sent: Thursday, April 30, 2020 11:42 PM To: Elad Cohen Subject: You have my vote! -- Sent from mobile Mul?umesc, Gabriel VOITIS -------------- next part -------------- An HTML attachment was scrubbed... URL: From oscar.wieman at MyBit.nl Thu Apr 30 22:43:29 2020 From: oscar.wieman at MyBit.nl (Oscar Wieman) Date: Thu, 30 Apr 2020 20:43:29 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: , Message-ID: Please people at RIPE, kick this man off the list. This is not the place for rfc?s as numerously told to him. How many more people have to unsubscribe first. And my apologies to the rest of you as being part of the problem. Regards, Oscar Wieman Verstuurd vanaf mijn iPhone Op 30 apr. 2020 om 22:35 heeft Munir Badr het volgende geschreven: ? Let the fun begin again!!! On Fri, 1 May 2020 at 00:31 Elad Cohen > wrote: Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/munir%40aeserver.com -- [https://i.ibb.co/RQQ6140/logo-aeserver-final.png] MUNIR BADR Book A Call: Click here Sales Hotline: 800 123 123 | Intl: +971 4 2493030 [https://i.ibb.co/X87cNSW/facebook.png] [https://i.ibb.co/PtLjz7w/twitter.png] [https://i.ibb.co/XY0qPKH/instagram.png] [https://i.ibb.co/RQNVxch/linkedin.png] _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/oscar.wieman%40mybit.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Thu Apr 30 22:44:33 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Thu, 30 Apr 2020 20:44:33 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: , <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> Message-ID: Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) ; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, 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. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn..... From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Thu Apr 30 22:44:23 2020 From: elad at netstyle.io (Elad Cohen) Date: Thu, 30 Apr 2020 20:44:23 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: , , Message-ID: Oscar is just supporting another candidate, which is afraid of me being elected, that is all. Respectfully, Ekad ________________________________ From: Oscar Wieman Sent: Thursday, April 30, 2020 11:43 PM To: Munir Badr Cc: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Please people at RIPE, kick this man off the list. This is not the place for rfc?s as numerously told to him. How many more people have to unsubscribe first. And my apologies to the rest of you as being part of the problem. Regards, Oscar Wieman Verstuurd vanaf mijn iPhone Op 30 apr. 2020 om 22:35 heeft Munir Badr het volgende geschreven: ? Let the fun begin again!!! On Fri, 1 May 2020 at 00:31 Elad Cohen > wrote: Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/munir%40aeserver.com -- [https://i.ibb.co/RQQ6140/logo-aeserver-final.png] MUNIR BADR Book A Call: Click here Sales Hotline: 800 123 123 | Intl: +971 4 2493030 [https://i.ibb.co/X87cNSW/facebook.png] [https://i.ibb.co/PtLjz7w/twitter.png] [https://i.ibb.co/XY0qPKH/instagram.png] [https://i.ibb.co/RQNVxch/linkedin.png] _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/oscar.wieman%40mybit.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From oscar.wieman at MyBit.nl Thu Apr 30 22:47:58 2020 From: oscar.wieman at MyBit.nl (Oscar Wieman) Date: Thu, 30 Apr 2020 20:47:58 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: , , , Message-ID: Hi Ekad, The only thing I have against you is my annoyance the past week of you making conspiracy theories and trying to push your stupid bullshit on all the people on this list. Enough is enough. Verstuurd vanaf mijn iPhone Op 30 apr. 2020 om 22:44 heeft Elad Cohen het volgende geschreven: ? Oscar is just supporting another candidate, which is afraid of me being elected, that is all. Respectfully, Ekad ________________________________ From: Oscar Wieman Sent: Thursday, April 30, 2020 11:43 PM To: Munir Badr Cc: Elad Cohen ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Please people at RIPE, kick this man off the list. This is not the place for rfc?s as numerously told to him. How many more people have to unsubscribe first. And my apologies to the rest of you as being part of the problem. Regards, Oscar Wieman Verstuurd vanaf mijn iPhone Op 30 apr. 2020 om 22:35 heeft Munir Badr het volgende geschreven: ? Let the fun begin again!!! On Fri, 1 May 2020 at 00:31 Elad Cohen > wrote: Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/munir%40aeserver.com -- [https://i.ibb.co/RQQ6140/logo-aeserver-final.png] MUNIR BADR Book A Call: Click here Sales Hotline: 800 123 123 | Intl: +971 4 2493030 [https://i.ibb.co/X87cNSW/facebook.png] [https://i.ibb.co/PtLjz7w/twitter.png] [https://i.ibb.co/XY0qPKH/instagram.png] [https://i.ibb.co/RQNVxch/linkedin.png] _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/oscar.wieman%40mybit.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.skrivan at serverzone.cz Thu Apr 30 22:41:58 2020 From: jaroslav.skrivan at serverzone.cz (=?utf-8?q?Jaroslav=20Sk=c5=99ivan?=) Date: Thu, 30 Apr 2020 20:41:58 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: <8a2556imdci2jftp7bqaqcgb.1588279038367@email.android.com> References: <8a2556imdci2jftp7bqaqcgb.1588279038367@email.android.com> Message-ID: I would love to use this feature as well. >Is there a way to unsubscribe from individual topics? I don't want to >be part of this fun... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Thu Apr 30 22:50:10 2020 From: elad at netstyle.io (Elad Cohen) Date: Thu, 30 Apr 2020 20:50:10 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: , <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> , Message-ID: Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen ; members-discuss at ripe.net Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) ; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, 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. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn?.. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Thu Apr 30 22:54:26 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Thu, 30 Apr 2020 20:54:26 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: , <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> , Message-ID: <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) ; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, 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. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn..... From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at cynthia.re Thu Apr 30 22:57:00 2020 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Thu, 30 Apr 2020 22:57:00 +0200 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: Message-ID: Please no more "technical solutions" on members-discuss! - Cynthia On Thu, Apr 30, 2020 at 10:31 PM Elad Cohen wrote: > Hello Ripe Members! > > 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. > > 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. > > 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. > > > 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) > > 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. > > > The Process: > > 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. > > In the new tracking ip packet there will be a new transport layer protocol > (tracking protocol) with the following fields: > AS number of source BGP router in clear text > AS number of source BGP router encrypted with the private key of the > source BGP router > > 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': > If 'off' then the destination BGP router will drop that 'tracking ip > packet' > > If 'on' then the destination BGP router will decrypt the 'encrypted AS > number' with the public key of the specific AS number > and after decryption the AS number need to be the result: > if not then to drop the tracking ip packet and the original ip packet > related to it > 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) > > > 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. > > 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. > > > > More Aspects: > > - 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. > - 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. > - Each BGP router will have all the public keys (of all the ASN's) locally. > - 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. > > > > 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'): > > - 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) > - 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. > - 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. > - 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). > - 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. > - 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. > > - 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. > - 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. > > > > 'Check tracking flag' in BGP Routers: > > - 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. > - The ICANN backend infrastructure through the session with the BGP router > - will be able to set the boolean value of the 'Check tracking flag'. > - 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. > - 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' > - 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. > - 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. > > > > Automatic preventation of IoT botnet infections: > > - 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. > - 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. > - 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. > - 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. > > > > Automatic prevention of botnet C&C ip addresses: > > - Botnets C&C are also a problem in the internet. > - 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. > - 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. > > > Respectfully, > Elad > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Thu Apr 30 22:59:05 2020 From: elad at netstyle.io (Elad Cohen) Date: Thu, 30 Apr 2020 20:59:05 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> References: , <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> , , <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> Message-ID: Stuart, The costs will be much much lower than the impacts of the following: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs If you prefer to stay with all the above ok lets stay with it all. If I will be elected you can be sure that I will do everything in my power to implement my solution that will resolve for all of it for all internet users. Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen ; members-discuss at ripe.net Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) ; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, 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. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn?.. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at safehosts.co.uk Thu Apr 30 23:01:04 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Thu, 30 Apr 2020 21:01:04 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: , <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> , , <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> Message-ID: <0f3a0ceb9aaa4ec893a1ef309d4c3636@safehosts.co.uk> Elad, As repeatedly explained to you, it simply is not possible to go around updating EVERY piece of hardware and software used for BGP sessions. I don't know why you can't comprehend this, so I am simply going to stop responding to you. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:59 To: Stuart Willet (primary) ; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, The costs will be much much lower than the impacts of the following: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs If you prefer to stay with all the above ok lets stay with it all. If I will be elected you can be sure that I will do everything in my power to implement my solution that will resolve for all of it for all internet users. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, 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. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn..... From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksi at magnacapax.fi Thu Apr 30 23:01:51 2020 From: aleksi at magnacapax.fi (Aleksi) Date: Fri, 1 May 2020 00:01:51 +0300 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> Message-ID: 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. 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 ... (everyone else, get the popcorn ready!) On 4/30/20 11:41 PM, Elad Cohen wrote: > Stuart, > > 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. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* Stuart Willet (primary) > *Sent:* Thursday, April 30, 2020 11:39 PM > *To:* Elad Cohen ; members-discuss at ripe.net > > *Subject:* RE: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > 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. > > Another idea, slightly marred by the unfathomable costs involved, > along with its logistic impossibility. > > /me sits back and grabs the popcorn?.. > > *From:*members-discuss [mailto:members-discuss-bounces at ripe.net] *On > Behalf Of *Elad Cohen > *Sent:* 30 April 2020 21:31 > *To:* members-discuss at ripe.net > *Subject:* [members-discuss] Technical solution to resolve Spoofed IP > traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT > botnet infections and Botnet C&Cs > > Hello Ripe Members! > > 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. > > 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. > > 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. > > 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) > > 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. > > The Process: > > 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. > > In the new tracking ip packet there will be a new transport layer > protocol (tracking protocol) with the following fields: > > AS number of source BGP router in clear text > > AS number of source BGP router encrypted with the private key of the > source BGP router > > 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': > > If 'off' then the destination BGP router will drop that 'tracking ip > packet' > > If 'on' then the destination BGP router will decrypt the 'encrypted AS > number' with the public key of the specific AS number > > and after decryption the AS number need to be the result: > > if not then to drop the tracking ip packet and the original ip packet > related to it > > 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) > > 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. > > 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. > > More Aspects: > > - 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. > > - 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. > > - Each BGP router will have all the public keys (of all the ASN's) > locally. > > - 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. > > 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'): > > - 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) > > - 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. > > - 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. > > - 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). > > - 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. > > - 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. > > - 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. > > - 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. > > 'Check tracking flag' in BGP Routers: > > - 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. > > - The ICANN backend infrastructure through the session with the BGP > router - will be able to set the boolean value of the 'Check tracking > flag'. > > - 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. > > - 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' > > - 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. > > - 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. > > Automatic preventation of IoT botnet infections: > > - 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. > > - 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. > > - 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. > > - 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. > > Automatic prevention of botnet C&C ip addresses: > > - Botnets C&C are also a problem in the internet. > > - 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. > > - 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. > > Respectfully, > > Elad > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias at brumm.net Thu Apr 30 23:04:19 2020 From: matthias at brumm.net (Matthias Brumm) Date: Thu, 30 Apr 2020 23:04:19 +0200 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: Message-ID: <6a97bc00-84dd-fadc-ff2c-69b24067fec3@brumm.net> 1. BGP routers are no IPS devices. 2. BGP routers have better things to do than doing crypto-stuff on a massive scale 3. at this point I suspected a joke (ok, the rest of the mail is just hilarious): > - 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. Am 30.04.20 um 22:30 schrieb Elad Cohen: > Hello Ripe Members! > > 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. > > 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. > > 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. > > > 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) > > 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. > > > The Process: > > 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. > > In the new tracking ip packet there will be a new transport layer > protocol (tracking protocol) with the following fields: > AS number of source BGP router in clear text > AS number of source BGP router encrypted with the private key of the > source BGP router > > 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': > If 'off' then the destination BGP router will drop that 'tracking ip > packet' > > If 'on' then the destination BGP router will decrypt the 'encrypted AS > number' with the public key of the specific AS number > and after decryption the AS number need to be the result: > if not then to drop the tracking ip packet and the original ip packet > related to it > 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) > > > 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. > > 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. > > > > More Aspects: > > - 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. > - 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. > - Each BGP router will have all the public keys (of all the ASN's) > locally. > - 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. > > > > 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'): > > - 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) > - 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. > - 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. > - 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). > - 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. > - 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. > > - 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. > - 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. > > > > 'Check tracking flag' in BGP Routers: > > - 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. > - The ICANN backend infrastructure through the session with the BGP > router - will be able to set the boolean value of the 'Check tracking > flag'. > - 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. > - 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' > - 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. > - 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. > > > > Automatic preventation of IoT botnet infections: > > - 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. > - 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. > - 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. > - 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. > > > > Automatic prevention of botnet C&C ip addresses: > > - Botnets C&C are also a problem in the internet. > - 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. > - 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. > > > Respectfully, > Elad > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Thu Apr 30 23:04:31 2020 From: elad at netstyle.io (Elad Cohen) Date: Thu, 30 Apr 2020 21:04:31 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: <0f3a0ceb9aaa4ec893a1ef309d4c3636@safehosts.co.uk> References: , <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> , , <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> , <0f3a0ceb9aaa4ec893a1ef309d4c3636@safehosts.co.uk> Message-ID: Stuart, All the bgp routers will be upgraded if I will be elected, you can be sure of it, including EOL routers, there is and there will be solution for anything. After it all internet users will enjoy from the end of: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking And the dramatically reducing of: IoT botnet infections and Botnet C&Cs Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Friday, May 1, 2020 12:01 AM To: Elad Cohen ; members-discuss at ripe.net Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, As repeatedly explained to you, it simply is not possible to go around updating EVERY piece of hardware and software used for BGP sessions. I don?t know why you can?t comprehend this, so I am simply going to stop responding to you. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:59 To: Stuart Willet (primary) ; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, The costs will be much much lower than the impacts of the following: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs If you prefer to stay with all the above ok lets stay with it all. If I will be elected you can be sure that I will do everything in my power to implement my solution that will resolve for all of it for all internet users. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, 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. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn?.. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at leoschabel.de Thu Apr 30 23:08:27 2020 From: mail at leoschabel.de (Leopold Schabel) Date: Thu, 30 Apr 2020 23:08:27 +0200 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: <8a2556imdci2jftp7bqaqcgb.1588279038367@email.android.com> References: <8a2556imdci2jftp7bqaqcgb.1588279038367@email.android.com> Message-ID: PSA for Google Mail users who do not want to be part of this conversation: there's a per-thread "mute" feature in the top-level menu. Am Do., 30. Apr. 2020 um 22:40 Uhr schrieb Bora Ismen < bora.ismen at nimbevo.com>: > Is there a way to unsubscribe from individual topics? I don't want to be > part of this fun... > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/mail%40leoschabel.de > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias at brumm.net Thu Apr 30 23:16:21 2020 From: matthias at brumm.net (Matthias Brumm) Date: Thu, 30 Apr 2020 23:16:21 +0200 Subject: [members-discuss] **SPAM** Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> Message-ID: Hi! What about the internet traffic in doubling every packet and the electrical power to do the cryptographic operations? Or do you want to make every router in the world stateful? As much as I would love to see you elected and make a complete fool of yourself, I can not risk the reputation of RIPE... At the moment I do not fancy any candidate, nor do I support one. Matthias Am 30.04.20 um 22:50 schrieb Elad Cohen: > Stuart, > > Not anyone can afford DDoS mitigation service and many in the Internet > don't have such service including in the Ripe region, and even for the > ones that are paying for expensive DDoS mitigation service -? DDoS > attacks are using internet traffic, are using electrical power, > interfering to access services, generating crime. If I will have the > honor of being elected then I will implement it all for the best of > everyone including negative members like you. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* Stuart Willet (primary) > *Sent:* Thursday, April 30, 2020 11:44 PM > *To:* Elad Cohen ; members-discuss at ripe.net > > *Subject:* RE: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > Elad, > > I have not attacked you, just pointing out the incredibly impossible > task you wish to be undertaken. > As for costs, we currently use a DDoS mitigation service. > > Your solution is not feasible, full stop. > > Respectfully, > > Stuart Willet. > > *From:*Elad Cohen [mailto:elad at netstyle.io] > *Sent:* 30 April 2020 21:42 > *To:* Stuart Willet (primary) ; > members-discuss at ripe.net > *Subject:* Re: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > Stuart, > > 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. > > Respectfully, > > Elad > > ------------------------------------------------------------------------ > > *From:*Stuart Willet (primary) > > *Sent:* Thursday, April 30, 2020 11:39 PM > *To:* Elad Cohen >; > members-discuss at ripe.net > > > *Subject:* RE: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > 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. > > Another idea, slightly marred by the unfathomable costs involved, > along with its logistic impossibility. > > /me sits back and grabs the popcorn?.. > > *From:*members-discuss [mailto:members-discuss-bounces at ripe.net] *On > Behalf Of *Elad Cohen > *Sent:* 30 April 2020 21:31 > *To:* members-discuss at ripe.net > *Subject:* [members-discuss] Technical solution to resolve Spoofed IP > traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT > botnet infections and Botnet C&Cs > > Hello Ripe Members! > > 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. > > 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. > > 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. > > 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) > > 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. > > The Process: > > 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. > > In the new tracking ip packet there will be a new transport layer > protocol (tracking protocol) with the following fields: > > AS number of source BGP router in clear text > > AS number of source BGP router encrypted with the private key of the > source BGP router > > 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': > > If 'off' then the destination BGP router will drop that 'tracking ip > packet' > > If 'on' then the destination BGP router will decrypt the 'encrypted AS > number' with the public key of the specific AS number > > and after decryption the AS number need to be the result: > > if not then to drop the tracking ip packet and the original ip packet > related to it > > 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) > > 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. > > 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. > > More Aspects: > > - 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. > > - 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. > > - Each BGP router will have all the public keys (of all the ASN's) > locally. > > - 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. > > 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'): > > - 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) > > - 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. > > - 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. > > - 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). > > - 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. > > - 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. > > - 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. > > - 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. > > 'Check tracking flag' in BGP Routers: > > - 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. > > - The ICANN backend infrastructure through the session with the BGP > router - will be able to set the boolean value of the 'Check tracking > flag'. > > - 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. > > - 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' > > - 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. > > - 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. > > Automatic preventation of IoT botnet infections: > > - 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. > > - 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. > > - 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. > > - 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. > > Automatic prevention of botnet C&C ip addresses: > > - Botnets C&C are also a problem in the internet. > > - 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. > > - 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. > > Respectfully, > > Elad > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Thu Apr 30 23:00:22 2020 From: elad at netstyle.io (Elad Cohen) Date: Thu, 30 Apr 2020 21:00:22 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: , Message-ID: Cynthia, This is a presentation that I will show in the near General Meeting. Respectfully, Elad ________________________________ From: Cynthia Revstr?m Sent: Thursday, April 30, 2020 11:57 PM To: Elad Cohen Cc: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Please no more "technical solutions" on members-discuss! - Cynthia On Thu, Apr 30, 2020 at 10:31 PM Elad Cohen > wrote: Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at velder.li Thu Apr 30 23:23:50 2020 From: lists at velder.li (Patrick Velder) Date: Thu, 30 Apr 2020 23:23:50 +0200 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> Message-ID: <680bb489-47d7-8cdd-6162-2809008a3ee4@velder.li> > The costs will be much much lower than the impacts of the following: > > Spoofed IP traffic hmmm. isn't the following spoofing too? > 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 On 30.04.20 22:59, Elad Cohen wrote: > Stuart, > > The costs will be much much lower than the impacts of the following: > > Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR > hijacking, IoT botnet infections and Botnet C&Cs > > If you prefer to stay with all the above ok lets stay with it all. > > If I will be elected you can be sure that I will do everything in my > power to implement my solution that will resolve for all of it for all > internet users. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* Stuart Willet (primary) > *Sent:* Thursday, April 30, 2020 11:54 PM > *To:* Elad Cohen ; members-discuss at ripe.net > > *Subject:* RE: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > Elad, > > Please show me the costing for your solution. > > In short, how much will it cost to update every piece of hardware and > software used in BGP sessions. > > How will you update all the END OF LIFE hardware and software? > > Stuart Willet. > > *From:*Elad Cohen [mailto:elad at netstyle.io] > *Sent:* 30 April 2020 21:50 > *To:* Stuart Willet (primary) ; > members-discuss at ripe.net > *Subject:* Re: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > Stuart, > > Not anyone can afford DDoS mitigation service and many in the Internet > don't have such service including in the Ripe region, and even for the > ones that are paying for expensive DDoS mitigation service -? DDoS > attacks are using internet traffic, are using electrical power, > interfering to access services, generating crime. If I will have the > honor of being elected then I will implement it all for the best of > everyone including negative members like you. > > Respectfully, > > Elad > > ------------------------------------------------------------------------ > > *From:*Stuart Willet (primary) > > *Sent:* Thursday, April 30, 2020 11:44 PM > *To:* Elad Cohen >; > members-discuss at ripe.net > > > *Subject:* RE: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > Elad, > > I have not attacked you, just pointing out the incredibly impossible > task you wish to be undertaken. > As for costs, we currently use a DDoS mitigation service. > > Your solution is not feasible, full stop. > > Respectfully, > > Stuart Willet. > > *From:*Elad Cohen [mailto:elad at netstyle.io] > *Sent:* 30 April 2020 21:42 > *To:* Stuart Willet (primary) >; members-discuss at ripe.net > > *Subject:* Re: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > Stuart, > > 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. > > Respectfully, > > Elad > > ------------------------------------------------------------------------ > > *From:*Stuart Willet (primary) > > *Sent:* Thursday, April 30, 2020 11:39 PM > *To:* Elad Cohen >; > members-discuss at ripe.net > > > *Subject:* RE: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > 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. > > Another idea, slightly marred by the unfathomable costs involved, > along with its logistic impossibility. > > /me sits back and grabs the popcorn?.. > > *From:*members-discuss [mailto:members-discuss-bounces at ripe.net] *On > Behalf Of *Elad Cohen > *Sent:* 30 April 2020 21:31 > *To:* members-discuss at ripe.net > *Subject:* [members-discuss] Technical solution to resolve Spoofed IP > traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT > botnet infections and Botnet C&Cs > > Hello Ripe Members! > > 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. > > 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. > > 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. > > 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) > > 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. > > The Process: > > 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. > > In the new tracking ip packet there will be a new transport layer > protocol (tracking protocol) with the following fields: > > AS number of source BGP router in clear text > > AS number of source BGP router encrypted with the private key of the > source BGP router > > 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': > > If 'off' then the destination BGP router will drop that 'tracking ip > packet' > > If 'on' then the destination BGP router will decrypt the 'encrypted AS > number' with the public key of the specific AS number > > and after decryption the AS number need to be the result: > > if not then to drop the tracking ip packet and the original ip packet > related to it > > 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) > > 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. > > 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. > > More Aspects: > > - 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. > > - 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. > > - Each BGP router will have all the public keys (of all the ASN's) > locally. > > - 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. > > 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'): > > - 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) > > - 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. > > - 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. > > - 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). > > - 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. > > - 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. > > - 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. > > - 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. > > 'Check tracking flag' in BGP Routers: > > - 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. > > - The ICANN backend infrastructure through the session with the BGP > router - will be able to set the boolean value of the 'Check tracking > flag'. > > - 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. > > - 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' > > - 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. > > - 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. > > Automatic preventation of IoT botnet infections: > > - 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. > > - 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. > > - 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. > > - 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. > > Automatic prevention of botnet C&C ip addresses: > > - Botnets C&C are also a problem in the internet. > > - 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. > > - 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. > > Respectfully, > > Elad > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/lists%40velder.li -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at cowmedia.de Thu Apr 30 23:27:48 2020 From: info at cowmedia.de (info at cowmedia.de) Date: Thu, 30 Apr 2020 23:27:48 +0200 Subject: [members-discuss] [SPAM] Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: , <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> , , <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> Message-ID: <141601d61f36$322e52c0$968af840$@cowmedia.de> Elad, 1st: Again a "technical" idea from your side that is not thought trough to the end. 2nd: If you will be elected (what i don't think because of you annoying mostly everyone here) you don't have the power to do what you expect. Still you need to convince other and still you need to create an RfC an so on, you are not able to convince other because you are rude and don't accept others oppinions 3rd: because you are rude you also do not have any requirements for the election and we should suggest RIPE to remove you from the list because of missing soft skills 4th: You wrote "bgp routers need to wait for X-number of seconds". Have you ever thought about what that means with 100 gbit/s devices? 5th: In addition again for mostly every packet you will ask a central service (that again communicates wich means packets are doubled, which result in overflooding of the network. 6th: i don't want to read any word from you here personally because it just annoyes me. Michael Stenz Von: members-discuss Im Auftrag von Elad Cohen Gesendet: Donnerstag, 30. April 2020 22:59 An: Stuart Willet (primary) ; members-discuss at ripe.net Betreff: [SPAM] Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, The costs will be much much lower than the impacts of the following: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs If you prefer to stay with all the above ok lets stay with it all. If I will be elected you can be sure that I will do everything in my power to implement my solution that will resolve for all of it for all internet users. Respectfully, Elad _____ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad _____ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, 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. Respectfully, Elad _____ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn... From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5533 bytes Desc: not available URL: From elad at netstyle.io Thu Apr 30 23:30:24 2020 From: elad at netstyle.io (Elad Cohen) Date: Thu, 30 Apr 2020 21:30:24 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> , Message-ID: Both of you supporting another candidate and that is perfectly fine, you can just say it clearly. We can keep being with DDoS attacks if you wish. Respectfully, Elad ________________________________ From: Tulp Solutions (O. Verheijen) Sent: Friday, May 1, 2020 12:27 AM To: Elad Cohen Cc: Stuart Willet (primary) ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please stop! There were no personal attacks, just different opinions. We clearly have a different opinion on what qualities one should have to get elected board member, but that's just fine, I don't feel attacked or offended by you. 'much much lower' is not a number, it does not work for me, especially when the only real requirement is that we should elect you first... @Stuart, is that sweet or salty popcorn you have there? Regards, Olof Op do 30 apr. 2020 om 22:59 schreef Elad Cohen >: Stuart, The costs will be much much lower than the impacts of the following: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs If you prefer to stay with all the above ok lets stay with it all. If I will be elected you can be sure that I will do everything in my power to implement my solution that will resolve for all of it for all internet users. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, 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. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn?.. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/olof%40tulpsolutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From joreilly at nellicus.net Thu Apr 30 23:33:52 2020 From: joreilly at nellicus.net (=?utf-8?Q?Justin_O=E2=80=99Reilly?=) Date: Thu, 30 Apr 2020 17:33:52 -0400 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: Message-ID: <66D20078-1E45-4862-A282-36A13596C0D4@nellicus.net> This is unacceptable the way you conduct yourself on these email lists. I have submit a formal complaint to RIPE it is a gross violation of community standards. Sent from my iPhone > On Apr 30, 2020, at 16:31, Elad Cohen wrote: > > ? > Hello Ripe Members! > > 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. > > 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. > > 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. > > > 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) > > 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. > > > The Process: > > 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. > > In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: > AS number of source BGP router in clear text > AS number of source BGP router encrypted with the private key of the source BGP router > > 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': > If 'off' then the destination BGP router will drop that 'tracking ip packet' > > If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number > and after decryption the AS number need to be the result: > if not then to drop the tracking ip packet and the original ip packet related to it > 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) > > > 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. > > 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. > > > > More Aspects: > > - 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. > - 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. > - Each BGP router will have all the public keys (of all the ASN's) locally. > - 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. > > > > 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'): > > - 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) > - 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. > - 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. > - 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). > - 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. > - 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. > > - 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. > - 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. > > > > 'Check tracking flag' in BGP Routers: > > - 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. > - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. > - 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. > - 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' > - 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. > - 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. > > > > Automatic preventation of IoT botnet infections: > > - 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. > - 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. > - 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. > - 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. > > > > Automatic prevention of botnet C&C ip addresses: > > - Botnets C&C are also a problem in the internet. > - 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. > - 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. > > > Respectfully, > Elad > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/joreilly%40nellicus.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image1.png Type: image/png Size: 744411 bytes Desc: not available URL: From ximaera at gmail.com Thu Apr 30 23:33:44 2020 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 1 May 2020 00:33:44 +0300 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: Message-ID: Peace, Trying to be as technical as I can here, On Thu, Apr 30, 2020 at 11:31 PM Elad Cohen wrote: > In the new tracking ip packet there will be a new > transport layer protocol (tracking protocol) with > the following fields: > AS number of source BGP router in clear text > AS number of source BGP router encrypted with the private key of the source BGP router So the secret part would be the same for all the packets. This technique is easily circumventable with tcpdump. Moreover, you're encrypting values from a less than 4-byte domain. I can pick the correct encrypted value with brute force. Proper cryptoanalysis would find more flaws in this. I just cherry picked instant weaknesses. > If 'on' then the destination BGP router will decrypt > the 'encrypted AS number' with the public key of > the specific AS number > and after decryption the AS number need to be > the result: > if not then to drop the tracking ip packet and the > original ip packet related to it > if yes then to drop the tracking ip packet and to > forward the related original ip packet to > destination This is not how border routers work. Those do not keep a packet in memory until some check-up would finish. They are *stateless* when it comes to forwarding packets, otherwise they could be DDoS'd much easily than today. IOW, they do not *know anything* about other packets while processing your "tracking packet". What if a tracking packet is lost in transit? What if it arrives an hour later? How long does it take for a router to drop a packet without a confirmation? "X number of seconds" is not a response. "Seconds" are a wrong unit of measurement. Nanoseconds, maybe. Seconds ? no go. That also assumes a hardware update to all the line cards. > - 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. Also if we can block all the weapon-producing plants there would be no war from that point on. Why don't you apply your genius to those certainly more important issues of the humanity? > any kind of automatic updating (in the operating > system configurations) will be disabled This is not how vulnerabilities work. They are frequently *introduced* by an update. I'm waiting for your financial analysis of the concept "let's keep a VM for every published CVE" (assuming that every actively exploited vulnerability even gets a CVE, which is also not how it works). > 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 This is not gonna work for P2P botnets. *** I must have missed other flaws, the e-mail is insanely tough to read (possibly intentionally). Anyhow, RIPE is *not* the place for such proposals. IETF secdispatch is (Gosh may Kathleen and Roman forgive me): secdispatch at ietf.org. -- T?ma From stu at safehosts.co.uk Thu Apr 30 23:35:06 2020 From: stu at safehosts.co.uk (Stuart Willet (primary)) Date: Thu, 30 Apr 2020 21:35:06 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> , Message-ID: <7e1a54aae30246e6b7e52d8efffe8f60@safehosts.co.uk> Elad, Your actions on this list are likely to have helped a lot of members decide who will get their support. I know you have helped me eliminate a candidate. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 22:30 To: Tulp Solutions (O. Verheijen) Cc: Stuart Willet (primary) ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Both of you supporting another candidate and that is perfectly fine, you can just say it clearly. We can keep being with DDoS attacks if you wish. Respectfully, Elad ________________________________ From: Tulp Solutions (O. Verheijen) > Sent: Friday, May 1, 2020 12:27 AM To: Elad Cohen > Cc: Stuart Willet (primary) >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please stop! There were no personal attacks, just different opinions. We clearly have a different opinion on what qualities one should have to get elected board member, but that's just fine, I don't feel attacked or offended by you. 'much much lower' is not a number, it does not work for me, especially when the only real requirement is that we should elect you first... @Stuart, is that sweet or salty popcorn you have there? Regards, Olof Op do 30 apr. 2020 om 22:59 schreef Elad Cohen >: Stuart, The costs will be much much lower than the impacts of the following: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs If you prefer to stay with all the above ok lets stay with it all. If I will be elected you can be sure that I will do everything in my power to implement my solution that will resolve for all of it for all internet users. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, 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. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn..... From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/olof%40tulpsolutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Thu Apr 30 23:36:40 2020 From: elad at netstyle.io (Elad Cohen) Date: Thu, 30 Apr 2020 21:36:40 +0000 Subject: [members-discuss] [SPAM] Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Message-ID: I agree with you, let us all keep with the ddos attacks and not resolve them. Respectfully, Elad ________________________________ From: info at cowmedia.de Sent: Friday, May 01, 2020 12:27 AM To: Elad Cohen; 'Stuart Willet (primary)'; members-discuss at ripe.net Subject: AW: [SPAM] Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, 1st: Again a ?technical? idea from your side that is not thought trough to the end. 2nd: If you will be elected (what i don?t think because of you annoying mostly everyone here) you don?t have the power to do what you expect. Still you need to convince other and still you need to create an RfC an so on, you are not able to convince other because you are rude and don?t accept others oppinions 3rd: because you are rude you also do not have any requirements for the election and we should suggest RIPE to remove you from the list because of missing soft skills 4th: You wrote ?bgp routers need to wait for X-number of seconds?. Have you ever thought about what that means with 100 gbit/s devices? 5th: In addition again for mostly every packet you will ask a central service (that again communicates wich means packets are doubled, which result in overflooding of the network. 6th: i don?t want to read any word from you here personally because it just annoyes me. Michael Stenz Von: members-discuss Im Auftrag von Elad Cohen Gesendet: Donnerstag, 30. April 2020 22:59 An: Stuart Willet (primary) ; members-discuss at ripe.net Betreff: [SPAM] Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, The costs will be much much lower than the impacts of the following: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs If you prefer to stay with all the above ok lets stay with it all. If I will be elected you can be sure that I will do everything in my power to implement my solution that will resolve for all of it for all internet users. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, 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. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn?.. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.hamel at essensys.tech Thu Apr 30 23:37:27 2020 From: ryan.hamel at essensys.tech (Ryan Hamel) Date: Thu, 30 Apr 2020 21:37:27 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: , <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> , , <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> , <0f3a0ceb9aaa4ec893a1ef309d4c3636@safehosts.co.uk> Message-ID: Elad, Can you explain why implementing uRPF (https://en.wikipedia.org/wiki/Reverse-path_forwarding#Unicast_RPF) as part of BCP38 would not work? It's a simple knob to enable on an interface of the post popular routing vendors and *NIX distributions, it's been around forever, it doesn't require the use of any routing protocol, or a central authority. Thanks, Ryan Hamel Network Support Engineer W: www.essensys.tech The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately by reply. ? essensys plc is a registered, public company in England and Wales. Registered Office: Aldgate Tower, ?Leman Street, London, E1 8FA essensys Inc is a Delaware company. Registered Office: 450 7th Avenue, New York, NY 10123 From: members-discuss On Behalf Of Elad Cohen Sent: Thursday, April 30, 2020 2:05 PM To: Stuart Willet (primary) ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, All the bgp routers will be upgraded if I will be elected, you can be sure of it, including EOL routers, there is and there will be solution for anything. After it all internet users will enjoy from the end of: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking And the dramatically reducing of: IoT botnet infections and Botnet C&Cs Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Friday, May 1, 2020 12:01 AM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, As repeatedly explained to you, it simply is not possible to go around updating EVERY piece of hardware and software used for BGP sessions. I don't know why you can't comprehend this, so I am simply going to stop responding to you. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:59 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, The costs will be much much lower than the impacts of the following: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs If you prefer to stay with all the above ok lets stay with it all. If I will be elected you can be sure that I will do everything in my power to implement my solution that will resolve for all of it for all internet users. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, 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. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn..... From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksi at magnacapax.fi Thu Apr 30 23:37:55 2020 From: aleksi at magnacapax.fi (Aleksi) Date: Fri, 1 May 2020 00:37:55 +0300 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> <0f3a0ceb9aaa4ec893a1ef309d4c3636@safehosts.co.uk> Message-ID: <935c9b1c-720a-239a-c2c6-c0643ba08172@magnacapax.fi> "All the bgp routers will be upgraded if I will be elected, you can be sure of it, including EOL routers, there is and there will be solution for anything." ROFLMAO! Can we have immortality with infinite money as well on the go? :) Or is this the type of promise where RIPE membership annual fee balloons by approximately 9 zeroes for every member, preferrably paid directly to Netstyle?? .... I suspect the latter ;) On 5/1/20 12:04 AM, Elad Cohen wrote: > Stuart, > > All the bgp routers will be upgraded if I will be elected, you can be > sure of it, including EOL routers, there is and there will be solution > for anything. > > After it all internet users will enjoy from the end of: > Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking > > And the dramatically reducing of: > IoT botnet infections and Botnet C&Cs > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* Stuart Willet (primary) > *Sent:* Friday, May 1, 2020 12:01 AM > *To:* Elad Cohen ; members-discuss at ripe.net > > *Subject:* RE: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > Elad, > > As repeatedly explained to you, it simply is not possible to go around > updating EVERY piece of hardware and software used for BGP sessions. > > I don?t know why you can?t comprehend this, so I am simply going to > stop responding to you. > > Respectfully, > > Stuart Willet. > > *From:*Elad Cohen [mailto:elad at netstyle.io] > *Sent:* 30 April 2020 21:59 > *To:* Stuart Willet (primary) ; > members-discuss at ripe.net > *Subject:* Re: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > Stuart, > > The costs will be much much lower than the impacts of the following: > > Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR > hijacking, IoT botnet infections and Botnet C&Cs > > If you prefer to stay with all the above ok lets stay with it all. > > If I will be elected you can be sure that I will do everything in my > power to implement my solution that will resolve for all of it for all > internet users. > > Respectfully, > > Elad > > ------------------------------------------------------------------------ > > *From:*Stuart Willet (primary) > > *Sent:* Thursday, April 30, 2020 11:54 PM > *To:* Elad Cohen >; > members-discuss at ripe.net > > > *Subject:* RE: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > Elad, > > Please show me the costing for your solution. > > In short, how much will it cost to update every piece of hardware and > software used in BGP sessions. > > How will you update all the END OF LIFE hardware and software? > > Stuart Willet. > > *From:*Elad Cohen [mailto:elad at netstyle.io] > *Sent:* 30 April 2020 21:50 > *To:* Stuart Willet (primary) >; members-discuss at ripe.net > > *Subject:* Re: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > Stuart, > > Not anyone can afford DDoS mitigation service and many in the Internet > don't have such service including in the Ripe region, and even for the > ones that are paying for expensive DDoS mitigation service -? DDoS > attacks are using internet traffic, are using electrical power, > interfering to access services, generating crime. If I will have the > honor of being elected then I will implement it all for the best of > everyone including negative members like you. > > Respectfully, > > Elad > > ------------------------------------------------------------------------ > > *From:*Stuart Willet (primary) > > *Sent:* Thursday, April 30, 2020 11:44 PM > *To:* Elad Cohen >; > members-discuss at ripe.net > > > *Subject:* RE: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > Elad, > > I have not attacked you, just pointing out the incredibly impossible > task you wish to be undertaken. > As for costs, we currently use a DDoS mitigation service. > > Your solution is not feasible, full stop. > > Respectfully, > > Stuart Willet. > > *From:*Elad Cohen [mailto:elad at netstyle.io] > *Sent:* 30 April 2020 21:42 > *To:* Stuart Willet (primary) >; members-discuss at ripe.net > > *Subject:* Re: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > Stuart, > > 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. > > Respectfully, > > Elad > > ------------------------------------------------------------------------ > > *From:*Stuart Willet (primary) > > *Sent:* Thursday, April 30, 2020 11:39 PM > *To:* Elad Cohen >; > members-discuss at ripe.net > > > *Subject:* RE: Technical solution to resolve Spoofed IP traffic, > Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet > infections and Botnet C&Cs > > 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. > > Another idea, slightly marred by the unfathomable costs involved, > along with its logistic impossibility. > > /me sits back and grabs the popcorn?.. > > *From:*members-discuss [mailto:members-discuss-bounces at ripe.net] *On > Behalf Of *Elad Cohen > *Sent:* 30 April 2020 21:31 > *To:* members-discuss at ripe.net > *Subject:* [members-discuss] Technical solution to resolve Spoofed IP > traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT > botnet infections and Botnet C&Cs > > Hello Ripe Members! > > 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. > > 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. > > 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. > > 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) > > 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. > > The Process: > > 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. > > In the new tracking ip packet there will be a new transport layer > protocol (tracking protocol) with the following fields: > > AS number of source BGP router in clear text > > AS number of source BGP router encrypted with the private key of the > source BGP router > > 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': > > If 'off' then the destination BGP router will drop that 'tracking ip > packet' > > If 'on' then the destination BGP router will decrypt the 'encrypted AS > number' with the public key of the specific AS number > > and after decryption the AS number need to be the result: > > if not then to drop the tracking ip packet and the original ip packet > related to it > > 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) > > 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. > > 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. > > More Aspects: > > - 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. > > - 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. > > - Each BGP router will have all the public keys (of all the ASN's) > locally. > > - 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. > > 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'): > > - 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) > > - 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. > > - 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. > > - 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). > > - 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. > > - 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. > > - 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. > > - 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. > > 'Check tracking flag' in BGP Routers: > > - 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. > > - The ICANN backend infrastructure through the session with the BGP > router - will be able to set the boolean value of the 'Check tracking > flag'. > > - 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. > > - 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' > > - 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. > > - 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. > > Automatic preventation of IoT botnet infections: > > - 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. > > - 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. > > - 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. > > - 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. > > Automatic prevention of botnet C&C ip addresses: > > - Botnets C&C are also a problem in the internet. > > - 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. > > - 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. > > Respectfully, > > Elad > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at fiberdirekt.se Thu Apr 30 23:38:13 2020 From: peter at fiberdirekt.se (Peter Linder) Date: Thu, 30 Apr 2020 23:38:13 +0200 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: , <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> , , <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> , <0f3a0ceb9aaa4ec893a1ef309d4c3636@safehosts.co.uk> Message-ID: The RIPE executive board has no say in such a matter. Elad Cohen skrev: (30 april 2020 23:04:31 CEST) >Stuart, > >All the bgp routers will be upgraded if I will be elected, you can be >sure of it, including EOL routers, there is and there will be solution >for anything. > >After it all internet users will enjoy from the end of: >Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR >hijacking > >And the dramatically reducing of: >IoT botnet infections and Botnet C&Cs > >Respectfully, >Elad >________________________________ >From: Stuart Willet (primary) >Sent: Friday, May 1, 2020 12:01 AM >To: Elad Cohen ; members-discuss at ripe.net > >Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed >amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections >and Botnet C&Cs > > >Elad, > > > >As repeatedly explained to you, it simply is not possible to go around >updating EVERY piece of hardware and software used for BGP sessions. > >I don?t know why you can?t comprehend this, so I am simply going to >stop responding to you. > > > >Respectfully, > > > >Stuart Willet. > > > >From: Elad Cohen [mailto:elad at netstyle.io] >Sent: 30 April 2020 21:59 >To: Stuart Willet (primary) ; >members-discuss at ripe.net >Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed >amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections >and Botnet C&Cs > > > >Stuart, > > > >The costs will be much much lower than the impacts of the following: > > > >Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR >hijacking, IoT botnet infections and Botnet C&Cs > > > >If you prefer to stay with all the above ok lets stay with it all. > > > >If I will be elected you can be sure that I will do everything in my >power to implement my solution that will resolve for all of it for all >internet users. > > > >Respectfully, > >Elad > >________________________________ > >From: Stuart Willet (primary) >> >Sent: Thursday, April 30, 2020 11:54 PM >To: Elad Cohen >; >members-discuss at ripe.net >> >Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed >amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections >and Botnet C&Cs > > > >Elad, > > > >Please show me the costing for your solution. > >In short, how much will it cost to update every piece of hardware and >software used in BGP sessions. > >How will you update all the END OF LIFE hardware and software? > > > > > >Stuart Willet. > > > >From: Elad Cohen [mailto:elad at netstyle.io] >Sent: 30 April 2020 21:50 >To: Stuart Willet (primary) >>; >members-discuss at ripe.net >Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed >amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections >and Botnet C&Cs > > > >Stuart, > > > >Not anyone can afford DDoS mitigation service and many in the Internet >don't have such service including in the Ripe region, and even for the >ones that are paying for expensive DDoS mitigation service - DDoS >attacks are using internet traffic, are using electrical power, >interfering to access services, generating crime. If I will have the >honor of being elected then I will implement it all for the best of >everyone including negative members like you. > > > >Respectfully, > >Elad > >________________________________ > >From: Stuart Willet (primary) >> >Sent: Thursday, April 30, 2020 11:44 PM >To: Elad Cohen >; >members-discuss at ripe.net >> >Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed >amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections >and Botnet C&Cs > > > >Elad, > > > >I have not attacked you, just pointing out the incredibly impossible >task you wish to be undertaken. >As for costs, we currently use a DDoS mitigation service. > > > >Your solution is not feasible, full stop. > > > >Respectfully, > > > >Stuart Willet. > > > >From: Elad Cohen [mailto:elad at netstyle.io] >Sent: 30 April 2020 21:42 >To: Stuart Willet (primary) >>; >members-discuss at ripe.net >Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed >amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections >and Botnet C&Cs > > > >Stuart, > > > >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. > > > >Respectfully, > >Elad > >________________________________ > >From: Stuart Willet (primary) >> >Sent: Thursday, April 30, 2020 11:39 PM >To: Elad Cohen >; >members-discuss at ripe.net >> >Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed >amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections >and Botnet C&Cs > > > >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. > >Another idea, slightly marred by the unfathomable costs involved, along >with its logistic impossibility. > > > >/me sits back and grabs the popcorn?.. > > > >From: members-discuss [mailto:members-discuss-bounces at ripe.net] On >Behalf Of Elad Cohen >Sent: 30 April 2020 21:31 >To: members-discuss at ripe.net >Subject: [members-discuss] Technical solution to resolve Spoofed IP >traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT >botnet infections and Botnet C&Cs > > > >Hello Ripe Members! > > > >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. > > > >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. > > > >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. > > > > > >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) > > > >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. > > > > > >The Process: > > > >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. > > > >In the new tracking ip packet there will be a new transport layer >protocol (tracking protocol) with the following fields: > >AS number of source BGP router in clear text > >AS number of source BGP router encrypted with the private key of the >source BGP router > > > >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': > >If 'off' then the destination BGP router will drop that 'tracking ip >packet' > > > >If 'on' then the destination BGP router will decrypt the 'encrypted AS >number' with the public key of the specific AS number > >and after decryption the AS number need to be the result: > >if not then to drop the tracking ip packet and the original ip packet >related to it > >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) > > > > > >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. > > > >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. > > > > > > > >More Aspects: > > > >- 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. > >- 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. > >- Each BGP router will have all the public keys (of all the ASN's) >locally. > >- 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. > > > > > > > >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'): > > > >- 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) > >- 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. > >- 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. > >- 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). > >- 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. > >- 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. > > > >- 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. > >- 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. > > > > > > > >'Check tracking flag' in BGP Routers: > > > >- 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. > >- The ICANN backend infrastructure through the session with the BGP >router - will be able to set the boolean value of the 'Check tracking >flag'. > >- 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. > >- 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' > >- 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. > >- 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. > > > > > > > >Automatic preventation of IoT botnet infections: > > > >- 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. > >- 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. > >- 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. > >- 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. > > > > > > > >Automatic prevention of botnet C&C ip addresses: > > > >- Botnets C&C are also a problem in the internet. > >- 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. > >- 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. > > > > > >Respectfully, > >Elad -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From elad at netstyle.io Thu Apr 30 23:38:37 2020 From: elad at netstyle.io (Elad Cohen) Date: Thu, 30 Apr 2020 21:38:37 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: <6a97bc00-84dd-fadc-ff2c-69b24067fec3@brumm.net> References: , <6a97bc00-84dd-fadc-ff2c-69b24067fec3@brumm.net> Message-ID: Yes, BGP routers need to handle all the DDoS attacks, it will be better for them. Respectfully, Elad ________________________________ From: members-discuss on behalf of Matthias Brumm Sent: Friday, May 1, 2020 12:04 AM To: members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 1. BGP routers are no IPS devices. 2. BGP routers have better things to do than doing crypto-stuff on a massive scale 3. at this point I suspected a joke (ok, the rest of the mail is just hilarious): - 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. Am 30.04.20 um 22:30 schrieb Elad Cohen: Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family -------------- next part -------------- An HTML attachment was scrubbed... URL: From nuclearcat at nuclearcat.com Thu Apr 30 23:24:55 2020 From: nuclearcat at nuclearcat.com (Denys Fedoryshchenko) Date: Fri, 01 May 2020 00:24:55 +0300 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: Message-ID: On 2020-04-30 23:30, Elad Cohen wrote: > Hello Ripe Members! > > 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. Your posts are offtopic and aren't within purpose of this maillist (Reference: Mailing List Purpose and Request for Consideration , from RIPE, Piotr Strzy?ewski, this Monday). It is frankly arrogant and not very smart ignoring that, and you keep trying to use this mailing list as an podium for election campaign. These "solutions" technically illiterate, hard-to-implement(not feasible in most of cases) ideas that look convincing only to people who do not have knowledge in the relevant fields, but to the anybody with experience look quite inadequate (most polite word for it). Meanwhile, i am surprised that someone liked this nonsense, i hope it was sarcasm. I really hope common sense exist and person who offers technically inadequate solutions that undermine existing standards, throw accusations left and right, build conspiracy theories, ignore purpose of maillists - will not be elected. P.S. For members who will vote, worth reading, especially second article: https://mybroadband.co.za/news/internet/330379-how-internet-resources-worth-r800-million-were-stolen-and-sold-on-the-black-market.html https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-address-heist-how-millions-are-made-on-the-grey-market.html From elad at netstyle.io Thu Apr 30 23:42:13 2020 From: elad at netstyle.io (Elad Cohen) Date: Thu, 30 Apr 2020 21:42:13 +0000 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: <7e1a54aae30246e6b7e52d8efffe8f60@safehosts.co.uk> References: <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> , , <7e1a54aae30246e6b7e52d8efffe8f60@safehosts.co.uk> Message-ID: Go ahead and tell the members exactly who do you support. Instead of each of your messages you can just write "I Support X", now you will probably deny that you support anyone. Respectfully, Elad ________________________________ From: Stuart Willet (primary) Sent: Friday, May 1, 2020 12:35 AM To: Elad Cohen ; Tulp Solutions (O. Verheijen) Cc: members-discuss at ripe.net Subject: RE: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Your actions on this list are likely to have helped a lot of members decide who will get their support. I know you have helped me eliminate a candidate. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 22:30 To: Tulp Solutions (O. Verheijen) Cc: Stuart Willet (primary) ; members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Both of you supporting another candidate and that is perfectly fine, you can just say it clearly. We can keep being with DDoS attacks if you wish. Respectfully, Elad ________________________________ From: Tulp Solutions (O. Verheijen) > Sent: Friday, May 1, 2020 12:27 AM To: Elad Cohen > Cc: Stuart Willet (primary) >; members-discuss at ripe.net > Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please stop! There were no personal attacks, just different opinions. We clearly have a different opinion on what qualities one should have to get elected board member, but that's just fine, I don't feel attacked or offended by you. 'much much lower' is not a number, it does not work for me, especially when the only real requirement is that we should elect you first... @Stuart, is that sweet or salty popcorn you have there? Regards, Olof Op do 30 apr. 2020 om 22:59 schreef Elad Cohen >: Stuart, The costs will be much much lower than the impacts of the following: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs If you prefer to stay with all the above ok lets stay with it all. If I will be elected you can be sure that I will do everything in my power to implement my solution that will resolve for all of it for all internet users. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad at netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) >; members-discuss at ripe.net Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, 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. Respectfully, Elad ________________________________ From: Stuart Willet (primary) > Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen >; members-discuss at ripe.net > Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs 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. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn?.. From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss at ripe.net Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! 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. 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. 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. 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) 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. The Process: 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. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router 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': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it 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) 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. 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. More Aspects: - 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. - 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. - Each BGP router will have all the public keys (of all the ASN's) locally. - 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. 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'): - 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) - 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. - 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. - 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). - 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. - 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. - 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. - 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. 'Check tracking flag' in BGP Routers: - 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. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - 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. - 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' - 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. - 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. Automatic preventation of IoT botnet infections: - 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. - 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. - 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. - 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. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - 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. - 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. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss at ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/olof%40tulpsolutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhr at fhrnet.eu Thu Apr 30 23:44:29 2020 From: fhr at fhrnet.eu (Filip Hruska) Date: Thu, 30 Apr 2020 23:44:29 +0200 Subject: [members-discuss] Enforcement of Code of Conduct on RIPE mailing lists? (WAS: Re: Technical solution to resolve Spoofed IP traffic...) In-Reply-To: References: Message-ID: <103ad167-1481-096b-80a7-a73a57ebdf50@fhrnet.eu> Dear all, May I remind you what the purpose of this list is? > This is a list for RIPE NCC members to discuss **membership-related issues.** 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. Quoting RIPE Mailing List Code of Conduct here: > 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.** 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. > 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. 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. Thank you very much. Best Regards, Filip Hru?ka On 4/30/20 10:57 PM, Cynthia Revstr?m wrote: > Please no more "technical solutions" on members-discuss! > > - Cynthia > > On Thu, Apr 30, 2020 at 10:31 PM Elad Cohen > wrote: > > Hello Ripe Members! > > 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. > > 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. > > 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. > > > 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) > > 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. > > > The Process: > > 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. > > In the new tracking ip packet there will be a new transport layer > protocol (tracking protocol) with the following fields: > AS number of source BGP router in clear text > AS number of source BGP router encrypted with the private key of > the source BGP router > > 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': > If 'off' then the destination BGP router will drop that 'tracking > ip packet' > > If 'on' then the destination BGP router will decrypt the > 'encrypted AS number' with the public key of the specific AS number > and after decryption the AS number need to be the result: > if not then to drop the tracking ip packet and the original ip > packet related to it > 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) > > > 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. > > 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. > > > > More Aspects: > > - 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. > - 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. > - Each BGP router will have all the public keys (of all the ASN's) > locally. > - 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. > > > > 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'): > > - 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) > - 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. > - 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. > - 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). > - 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. > - 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. > > - 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. > - 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. > > > > 'Check tracking flag' in BGP Routers: > > - 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. > - The ICANN backend infrastructure through the session with the > BGP router - will be able to set the boolean value of the 'Check > tracking flag'. > - 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. > - 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' > - 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. > - 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. > > > > Automatic preventation of IoT botnet infections: > > - 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. > - 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. > - 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. > - 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. > > > > Automatic prevention of botnet C&C ip addresses: > > - Botnets C&C are also a problem in the internet. > - 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. > - 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. > > > Respectfully, > Elad > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re > > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/fhr%40fhrnet.eu -- Filip Hruska Linux System Administrator -------------- next part -------------- An HTML attachment was scrubbed... URL: From aveline at misaka.io Thu Apr 30 23:39:30 2020 From: aveline at misaka.io (Siyuan Miao) Date: Fri, 1 May 2020 05:39:30 +0800 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: <8a2556imdci2jftp7bqaqcgb.1588279038367@email.android.com> Message-ID: Hi Elad, Do you really know how AnyCast work? It's not a silver bullet to solve these problems. Stop it. Get some help :-) https://www.youtube.com/watch?v=l60MnDJklnM On Fri, May 1, 2020 at 5:35 AM Leopold Schabel wrote: > PSA for Google Mail users who do not want to be part of this conversation: > there's a per-thread "mute" feature in the top-level menu. > > > Am Do., 30. Apr. 2020 um 22:40 Uhr schrieb Bora Ismen < > bora.ismen at nimbevo.com>: > >> Is there a way to unsubscribe from individual topics? I don't want to be >> part of this fun... >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: >> https://lists.ripe.net/mailman/options/members-discuss/mail%40leoschabel.de >> > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/aveline%40misaka.io > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marx at ama-networx.net Thu Apr 30 23:48:54 2020 From: marx at ama-networx.net (Andrae Marx) Date: Thu, 30 Apr 2020 23:48:54 +0200 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: <45587b39616447a3b2306cf5f0e10a97@safehosts.co.uk> <63dac48ff4414c038153a9bbd5d59faf@safehosts.co.uk> <0f3a0ceb9aaa4ec893a1ef309d4c3636@safehosts.co.uk> Message-ID: <026D68D2-5037-4D17-AC73-D8E0BFE2C0DD@ama-networx.net> -- Andrae Marx > Am 30.04.2020 um 23:04 schrieb Elad Cohen : > > Stuart, > > All the bgp routers will be upgraded if I will be elected, you can be sure of it, including EOL routers, there is and there will be solution for anything. My i suggest, if you getg voted, that you also change the following things in these planed upgrades, to all bgp related routing devices in the whole internet: - missing ipv6 support on old EOL devices - missing rpki features on old devices - missing support for 4-byte ASN?s on old devices - adding more ressources (cpu, ram) on older routers, which actually are in trouble with these ressources, keeping the whole routing-table, which might not get better, by extending now bgp, with additional information ?. (older routers, are limited in these ressources and can not be upgraded) There is a reason, why we have since 20 years IPv6 and it is not fully rolled out and working on the whole world ?. there is a reason, why we are not able to change the whole smtp, and have to build work arounds to reduce and filter spam ?. We also need to change smtp ?. dns ?. and maybe everyone should filter udp ?. or we just do a fully lockdown of the internet ?.. To be really sure, we also can just power off all routers on the world ?. no spam any more ?. no DDoS attacks any more ?. To be serous ?. upgrading all and every device on the world, which is speaking bgp, is just not possible ?. This is my technical point of view ?. My personal point of view is, that this list, should not be used, to discuss this topics here, it was several times told in the last days ? and again, the same thing ?. There is a way, to present these things ?. answering on the call of papers, for the ripe meetings, and doing a presentation there regards, Andi -- Andrae Marx -------------- next part -------------- An HTML attachment was scrubbed... URL: From melchior at aelmans.eu Thu Apr 30 23:57:27 2020 From: melchior at aelmans.eu (Melchior Aelmans) Date: Thu, 30 Apr 2020 23:57:27 +0200 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: Message-ID: As this idea is talking about BGP implementations I think this would belong in the IDR WG in IETF? On Thu, Apr 30, 2020 at 10:32 PM Elad Cohen wrote: > Hello Ripe Members! > > 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. > > 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. > > 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. > > > 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) > > 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. > > > The Process: > > 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. > > In the new tracking ip packet there will be a new transport layer protocol > (tracking protocol) with the following fields: > AS number of source BGP router in clear text > AS number of source BGP router encrypted with the private key of the > source BGP router > > 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': > If 'off' then the destination BGP router will drop that 'tracking ip > packet' > > If 'on' then the destination BGP router will decrypt the 'encrypted AS > number' with the public key of the specific AS number > and after decryption the AS number need to be the result: > if not then to drop the tracking ip packet and the original ip packet > related to it > 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) > > > 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. > > 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. > > > > More Aspects: > > - 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. > - 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. > - Each BGP router will have all the public keys (of all the ASN's) locally. > - 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. > > > > 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'): > > - 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) > - 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. > - 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. > - 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). > - 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. > - 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. > > - 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. > - 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. > > > > 'Check tracking flag' in BGP Routers: > > - 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. > - The ICANN backend infrastructure through the session with the BGP router > - will be able to set the boolean value of the 'Check tracking flag'. > - 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. > - 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' > - 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. > - 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. > > > > Automatic preventation of IoT botnet infections: > > - 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. > - 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. > - 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. > - 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. > > > > Automatic prevention of botnet C&C ip addresses: > > - Botnets C&C are also a problem in the internet. > - 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. > - 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. > > > Respectfully, > Elad > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/ripe-members-discussion%40coloclue.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Thu Apr 30 23:58:52 2020 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 1 May 2020 00:58:52 +0300 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: Message-ID: Ah yes!! On Thu, Apr 30, 2020 at 11:31 PM Elad Cohen wrote: > - 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. Everywhere except for China and, possibly, North Korea, border routers are *not* DPI devices. Hence they don't have an *ability* to *look* through the IP packet data, let alone apply any checksums or fingerprints. Otherwise, gosh, TCP with its checksums wouldn't have been necessary. A DPI device costs I think 500 times more than a typical border routing device in use in Europe. (this is a rough estimation based on the packet length, it might be slight less or a couple orders of magnitude more than that) And yes. This solution requires a complete *hardware* update to all the border routers. I think that's a concept for a PhD topic in economy (quite possibly also a Nobel prize) rather than for a members-discuss thread. P.S. I want to reiterate that those topics are relevant to secdispatch at ietf.org. Only after they are submitted as an I-D and dispatched to a working group, AND the working group accepts the I-D as a working group draft, they are on-topic in here. Otherwise, they are off-topic. Thank you in advance for understanding. -- T?ma From gert at space.net Thu Apr 30 23:21:01 2020 From: gert at space.net (Gert Doering) Date: Thu, 30 Apr 2020 23:21:01 +0200 Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In-Reply-To: References: Message-ID: <20200430212101.GR92477@Space.Net> Hi, On Thu, Apr 30, 2020 at 08:30:48PM +0000, Elad Cohen wrote: > 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. "Vote for me, and you shall have bread and circuses - and if not, you will have to stay miserable forever!" Am I summarizing this correctly? (This approach worked brilliantly in the past, but in the long run, the roman empire fell...) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: