Thanks for sharing. I see this has been around a while, but I hadn’t run
into it myself yet.
Apple is currently doing something like this with IPSEC and IPv6 for iCloud users; pretty much any iCloud user is always on a private VPN with all their other iCloud devices. And there are commercial enterprise SD-WAN products and cloud providers that offer a similar approach for SMBs and branch offices. Azure and AWS offer almost exactly this between virtual networks, data centers, and regions, down to the private ASNs.
It’s nice to see a project built on open standards for the express purpose of playing with it and learning about it. Seems very much like something 44net could benefit from studying carefully.
From: KUN LIN dnwk@linkun.info
To: "44net@mailman.ampr.org" 44net@mailman.ampr.org Cc: Bcc: Date: Thu, 2 Dec 2021 18:48:49 +0000 Subject: [44net] DN42 for 44net?
Just discover this new thing where it will create mesh networks and even BGP via VPN tunnels. This maybe an interesting way for 44net to considering implement.
dn42 is a big dynamic VPN< https://en.wikipedia.org/wiki/Virtual_private_network%3E, which employs Internet technologies (BGPhttps://en.wikipedia.org/wiki/Bgp, whois database, DNShttps://en.wikipedia.org/wiki/Domain_Name_System, etc). Participants connect to each other using network tunnels (GRE< https://dn42.dev/howto/GRE-on-FreeBSD%3E, OpenVPN< https://dn42.dev/howto/openvpn%3E, WireGuard< https://dn42.dev/howto/wireguard%3E, Tinchttps://dn42.dev/howto/tinc, IPsechttps://dn42.dev/howto/IPsec-with-PublicKeys) and exchange routes thanks to the Border Gateway Protocol. Network addresses are assigned in the 172.20.0.0/14 range and private AS numbers are used (see registry< https://dn42.dev/services/Whois%3E) as well as IPv6 addresses from the ULA-Range (fd00::/8) –
I feel like 44net need to move on from existing customized IPIP tunnel and onto something more modern. Existing tunnel could be kept for backward compatibility. Kun
________________________________ From: 44Net 44net-bounces+dnwk=linkun.info@mailman.ampr.org on behalf of John Burwell via 44Net 44net@mailman.ampr.org Sent: Thursday, December 2, 2021 13:01 To: 44net@mailman.ampr.org 44net@mailman.ampr.org Cc: John Burwell john@b-wells.us Subject: Re: [44net] DN42 for 44net?
Thanks for sharing. I see this has been around a while, but I hadn’t run
into it myself yet.
Apple is currently doing something like this with IPSEC and IPv6 for iCloud users; pretty much any iCloud user is always on a private VPN with all their other iCloud devices. And there are commercial enterprise SD-WAN products and cloud providers that offer a similar approach for SMBs and branch offices. Azure and AWS offer almost exactly this between virtual networks, data centers, and regions, down to the private ASNs.
It’s nice to see a project built on open standards for the express purpose of playing with it and learning about it. Seems very much like something 44net could benefit from studying carefully.
From: KUN LIN dnwk@linkun.info
To: "44net@mailman.ampr.org" 44net@mailman.ampr.org Cc: Bcc: Date: Thu, 2 Dec 2021 18:48:49 +0000 Subject: [44net] DN42 for 44net?
Just discover this new thing where it will create mesh networks and even BGP via VPN tunnels. This maybe an interesting way for 44net to considering implement.
dn42 is a big dynamic VPN< https://en.wikipedia.org/wiki/Virtual_private_network%3E, which employs Internet technologies (BGPhttps://en.wikipedia.org/wiki/Bgp, whois database, DNShttps://en.wikipedia.org/wiki/Domain_Name_System, etc). Participants connect to each other using network tunnels (GRE< https://dn42.dev/howto/GRE-on-FreeBSD%3E, OpenVPN< https://dn42.dev/howto/openvpn%3E, WireGuard< https://dn42.dev/howto/wireguard%3E, Tinchttps://dn42.dev/howto/tinc, IPsechttps://dn42.dev/howto/IPsec-with-PublicKeys) and exchange routes thanks to the Border Gateway Protocol. Network addresses are assigned in the 172.20.0.0/14 range and private AS numbers are used (see registry< https://dn42.dev/services/Whois%3E) as well as IPv6 addresses from the ULA-Range (fd00::/8) –
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
I've been working with BGP, Unix-like OS, and networks a decent amount, so here's my two cents.
IPIP has a significant advantage that it's dead simple to operate and that it works on most Unix-like operating systems (and cisco routers), however it's a very rudimentary protocol, inferior to even GRE. Considering that hamradio doesn't allow encryption, OpenVPN and Wireguard are off the table. What I think would be cooler is if we tried to run local tunneling services. I think we have a lot of people in our community who are well-educated in the radio part of AMPRnet, and others who are well-educated in the internet part of it. Localizing the AMPRnet tunnels would bring local communities closer together.
Another point maybe worth considering is dropping RIP44 altogether (because it's a non standard protocol) and replacing it with a BGP route reflector. Then a transition to a more DN42-like network could be easier because we wouldn't need to invent our own standards.
73
On 2. 12. 21 22:45, KUN LIN via 44Net wrote:
I feel like 44net need to move on from existing customized IPIP tunnel and onto something more modern. Existing tunnel could be kept for backward compatibility. Kun
From: 44Net 44net-bounces+dnwk=linkun.info@mailman.ampr.org on behalf of John Burwell via 44Net 44net@mailman.ampr.org Sent: Thursday, December 2, 2021 13:01 To: 44net@mailman.ampr.org 44net@mailman.ampr.org Cc: John Burwell john@b-wells.us Subject: Re: [44net] DN42 for 44net?
Thanks for sharing. I see this has been around a while, but I hadn’t run
into it myself yet.
Apple is currently doing something like this with IPSEC and IPv6 for iCloud users; pretty much any iCloud user is always on a private VPN with all their other iCloud devices. And there are commercial enterprise SD-WAN products and cloud providers that offer a similar approach for SMBs and branch offices. Azure and AWS offer almost exactly this between virtual networks, data centers, and regions, down to the private ASNs.
It’s nice to see a project built on open standards for the express purpose of playing with it and learning about it. Seems very much like something 44net could benefit from studying carefully.
From: KUN LIN dnwk@linkun.info
To: "44net@mailman.ampr.org" 44net@mailman.ampr.org Cc: Bcc: Date: Thu, 2 Dec 2021 18:48:49 +0000 Subject: [44net] DN42 for 44net?
Just discover this new thing where it will create mesh networks and even BGP via VPN tunnels. This maybe an interesting way for 44net to considering implement.
dn42 is a big dynamic VPN< https://en.wikipedia.org/wiki/Virtual_private_network%3E, which employs Internet technologies (BGPhttps://en.wikipedia.org/wiki/Bgp, whois database, DNShttps://en.wikipedia.org/wiki/Domain_Name_System, etc). Participants connect to each other using network tunnels (GRE< https://dn42.dev/howto/GRE-on-FreeBSD%3E, OpenVPN< https://dn42.dev/howto/openvpn%3E, WireGuard< https://dn42.dev/howto/wireguard%3E, Tinchttps://dn42.dev/howto/tinc, IPsechttps://dn42.dev/howto/IPsec-with-PublicKeys) and exchange routes thanks to the Border Gateway Protocol. Network addresses are assigned in the 172.20.0.0/14 range and private AS numbers are used (see registry< https://dn42.dev/services/Whois%3E) as well as IPv6 addresses from the ULA-Range (fd00::/8) –
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
On Dec 2, 2021, at 3:38 PM, Kristjan Komloši via 44Net 44net@mailman.ampr.org wrote:
I've been working with BGP, Unix-like OS, and networks a decent amount, so here's my two cents.
IPIP has a significant advantage that it's dead simple to operate and that it works on most Unix-like operating systems (and cisco routers), however it's a very rudimentary protocol, inferior to even GRE. Considering that hamradio doesn't allow encryption, OpenVPN and Wireguard are off the table. What I think would be cooler is if we tried to run local tunneling services. I think we have a lot of people in our community who are well-educated in the radio part of AMPRnet, and others who are well-educated in the internet part of it. Localizing the AMPRnet tunnels would bring local communities closer together.
Another point maybe worth considering is dropping RIP44 altogether (because it's a non standard protocol) and replacing it with a BGP route reflector. Then a transition to a more DN42-like network could be easier because we wouldn't need to invent our own standards.
73
On 2. 12. 21 22:45, KUN LIN via 44Net wrote:
I feel like 44net need to move on from existing customized IPIP tunnel and onto something more modern. Existing tunnel could be kept for backward compatibility. Kun
From: 44Net 44net-bounces+dnwk=linkun.info@mailman.ampr.org on behalf of John Burwell via 44Net 44net@mailman.ampr.org Sent: Thursday, December 2, 2021 13:01 To: 44net@mailman.ampr.org 44net@mailman.ampr.org Cc: John Burwell john@b-wells.us Subject: Re: [44net] DN42 for 44net?
Thanks for sharing. I see this has been around a while, but I hadn’t run
into it myself yet.
Apple is currently doing something like this with IPSEC and IPv6 for iCloud users; pretty much any iCloud user is always on a private VPN with all their other iCloud devices. And there are commercial enterprise SD-WAN products and cloud providers that offer a similar approach for SMBs and branch offices. Azure and AWS offer almost exactly this between virtual networks, data centers, and regions, down to the private ASNs.
It’s nice to see a project built on open standards for the express purpose of playing with it and learning about it. Seems very much like something 44net could benefit from studying carefully.
From: KUN LIN dnwk@linkun.info
To: "44net@mailman.ampr.org" 44net@mailman.ampr.org Cc: Bcc: Date: Thu, 2 Dec 2021 18:48:49 +0000 Subject: [44net] DN42 for 44net?
Just discover this new thing where it will create mesh networks and even BGP via VPN tunnels. This maybe an interesting way for 44net to considering implement.
dn42 is a big dynamic VPN< https://en.wikipedia.org/wiki/Virtual_private_network%3E, which employs Internet technologies (BGPhttps://en.wikipedia.org/wiki/Bgp, whois database, DNShttps://en.wikipedia.org/wiki/Domain_Name_System, etc). Participants connect to each other using network tunnels (GRE< https://dn42.dev/howto/GRE-on-FreeBSD%3E, OpenVPN< https://dn42.dev/howto/openvpn%3E, WireGuard< https://dn42.dev/howto/wireguard%3E, Tinchttps://dn42.dev/howto/tinc, IPsechttps://dn42.dev/howto/IPsec-with-PublicKeys) and exchange routes thanks to the Border Gateway Protocol. Network addresses are assigned in the 172.20.0.0/14 range and private AS numbers are used (see registry< https://dn42.dev/services/Whois%3E) as well as IPv6 addresses from the ULA-Range (fd00::/8) –
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world.
Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions.
— Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
Speaking for the UK
Licence term 11(2)b:
Messages sent from the station shall not be encrypted for the purposes of
rendering the Message unintelligible to other radio spectrum users.
https://www.ofcom.org.uk/__data/assets/pdf_file/0027/62991/amateur-terms.pdf
On Fri, 3 Dec 2021 at 17:46, Dave Gingrich via 44Net 44net@mailman.ampr.org wrote:
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world.
Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions.
— Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org
wrote:
Something to keep in mind: the USA encryption restriction only applies
to traffic going over the air.
Networks can and do have encryption as long as relay over air has
information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On Fri, 3 Dec 2021, Tom M0LTE via 44Net wrote:
Speaking for the UK
Licence term 11(2)b:
Messages sent from the station shall not be encrypted for the purposes of
rendering the Message unintelligible to other radio spectrum users.
https://www.ofcom.org.uk/__data/assets/pdf_file/0027/62991/amateur-terms.pdf
Again, the above scope is limited to radio spectrum, not IP connectivity.
-- Kris Kirby, KE4AHR Disinformation Architect, Systems Mangler, & Network Mismanager
Consider running your Ubiqiti/MikroTik/etc encrypted links under Part 15 not Part 97.
Tim
On 12/3/21 10:26 AM, Kris Kirby via 44Net wrote:
On Fri, 3 Dec 2021, Tom M0LTE via 44Net wrote:
Speaking for the UK
Licence term 11(2)b:
Messages sent from the station shall not be encrypted for the purposes of
rendering the Message unintelligible to other radio spectrum users.
https://www.ofcom.org.uk/__data/assets/pdf_file/0027/62991/amateur-terms.pdf
Again, the above scope is limited to radio spectrum, not IP connectivity.
-- Kris Kirby, KE4AHR Disinformation Architect, Systems Mangler, & Network Mismanager _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hi Kris
Can you elaborate on what you mean by this please? In my view IP connectivity over the amateur service must absolutely be within scope of the UK licence.
Cheers Tom
On Fri, 3 Dec 2021 at 18:28, Kris Kirby via 44Net 44net@mailman.ampr.org wrote:
On Fri, 3 Dec 2021, Tom M0LTE via 44Net wrote:
Speaking for the UK
Licence term 11(2)b:
Messages sent from the station shall not be encrypted for the purposes
of
rendering the Message unintelligible to other radio spectrum users.
https://www.ofcom.org.uk/__data/assets/pdf_file/0027/62991/amateur-terms.pdf
Again, the above scope is limited to radio spectrum, not IP connectivity.
-- Kris Kirby, KE4AHR Disinformation Architect, Systems Mangler, & Network Mismanager _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Please refer to § 97.113(a)(4) Prohibited transmissions...
(4) [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein [...]
Tim
On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote:
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world.
Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions.
— Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
That is referencing phone ops, transmitting music, and coded words to hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today, that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote:
Please refer to § 97.113(a)(4) Prohibited transmissions...
(4) [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein [...]
Tim
On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote:
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world. Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions. — Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
There have been two attempts to get the FCC to allow encryption in Part 97. RM-11699 in 2013 and RM-11831 in 2019. Both have been dismissed by the FCC. Please read these petitions and you will see that encryption is not allowed.
Tim
On 12/3/21 10:32 AM, Dave Gingrich via 44Net wrote:
That is referencing phone ops, transmitting music, and coded words to hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today, that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote:
Please refer to § 97.113(a)(4) Prohibited transmissions...
(4) [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein [...]
Tim
On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote:
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world. Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions. — Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Believe me... I would love to see encryption allowed. You are right that most IP traffic is wrapped in some sort of encryption such as TLS. Encryption is not only used to "obscure" traffic, but as a mechanism to authenticate end-to-end paths.
Tim
On 12/3/21 10:42 AM, Tim Požar via 44Net wrote:
There have been two attempts to get the FCC to allow encryption in Part 97. RM-11699 in 2013 and RM-11831 in 2019. Both have been dismissed by the FCC. Please read these petitions and you will see that encryption is not allowed.
Tim
On 12/3/21 10:32 AM, Dave Gingrich via 44Net wrote:
That is referencing phone ops, transmitting music, and coded words to hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today, that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote:
Please refer to § 97.113(a)(4) Prohibited transmissions...
(4) [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein [...]
Tim
On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote:
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world. Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions. — Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
All of what I just said, I don't mean to say I support encryption over the air or not. I really don't have an opinion either way. Just since that's the law, reasonable efforts have to be made.
Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me On 2021-12-03 12:47 p.m., Tim Požar via 44Net wrote:
Believe me... I would love to see encryption allowed. You are right that most IP traffic is wrapped in some sort of encryption such as TLS. Encryption is not only used to "obscure" traffic, but as a mechanism to authenticate end-to-end paths.
Tim
On 12/3/21 10:42 AM, Tim Požar via 44Net wrote:
There have been two attempts to get the FCC to allow encryption in Part 97. RM-11699 in 2013 and RM-11831 in 2019. Both have been dismissed by the FCC. Please read these petitions and you will see that encryption is not allowed.
Tim
On 12/3/21 10:32 AM, Dave Gingrich via 44Net wrote:
That is referencing phone ops, transmitting music, and coded words to hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today, that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote:
Please refer to § 97.113(a)(4) Prohibited transmissions...
(4) [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein [...]
Tim
On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote:
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world. Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions. — Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
To speak for the Canadian side of things, to my knowledge of the regulations here. Over the air encryption is a no no. But if it's not over the air, it's not a problem. Just like the US.
Regarding what to do about encryption that is sent over the air. I've thought about this in regards to a packet radio network I may end up deploying. I would simply block the ports at the NAT edge on which most encryption is done over. 443, 993, 995, among countless others that don't come to my mind as of now. And if needed, a firewall flagging traffic that has TLS or some other encryption on it for manual review and investigation and/or block it at that time.
I've accepted that there will be some encryption going over the air on packet radio networks. However my stance on the matter is to try and reduce it, educate operators about how to not accidentally, and employ firewall rules. And I wouldn't think regulators in most countries would go after such networks upon seeing reasonable best efforts are being made.
Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me On 2021-12-03 12:42 p.m., Tim Požar via 44Net wrote:
There have been two attempts to get the FCC to allow encryption in Part 97. RM-11699 in 2013 and RM-11831 in 2019. Both have been dismissed by the FCC. Please read these petitions and you will see that encryption is not allowed.
Tim
On 12/3/21 10:32 AM, Dave Gingrich via 44Net wrote:
That is referencing phone ops, transmitting music, and coded words to hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today, that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote:
Please refer to § 97.113(a)(4) Prohibited transmissions...
(4) [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein [...]
Tim
On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote:
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world. Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions. — Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On the internet, everything is going towards "encrypted". Even information that is completely public "has to be encrypted" these days, or otherwise browsers and other applications are constantly nagging the user that it is "insecure", "unsafe", "dangerous" etc. Educating users that they should avoid encryption is going to be ever harder, and the options will be less and less. (unencrypted protocols are being deprecated wherever you look)
So that is going to be a tough battle...
Rob
On 12/3/21 7:53 PM, Keaton VE5LPL via 44Net wrote:
I've accepted that there will be some encryption going over the air on packet radio networks. However my stance on the matter is to try and reduce it, educate operators about how to not accidentally, and employ firewall rules.
Unfortunately, compression is considered a type of encryption so also a no no over the air. Apparently, even a common well-documented type such as ZIP.
We could run SSL with a NULL cipher over the air. Not much gain from that, though, because the HMAC is made to detect small number of bit errors, but not at the rates we likely see over the air. And it is detection only, no correction.
Cliff K6CLS CM87
On December 3, 2021 10:42:56 AM PST, "Tim Požar via 44Net" 44net@mailman.ampr.org wrote:
There have been two attempts to get the FCC to allow encryption in Part 97. RM-11699 in 2013 and RM-11831 in 2019. Both have been dismissed by the FCC. Please read these petitions and you will see that encryption is not allowed.
Tim
On 12/3/21 10:32 AM, Dave Gingrich via 44Net wrote:
That is referencing phone ops, transmitting music, and coded words to hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today, that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote:
Please refer to § 97.113(a)(4) Prohibited transmissions...
(4) [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein [...]
Tim
On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote:
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world. Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions. — Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Compression is never encryption!!!!!! Also change the subject.
From: Cliff Sojourner via 44Netmailto:44net@mailman.ampr.org Sent: Friday, December 3, 2021 11:10 AM To: 44Net general discussionmailto:44net@mailman.ampr.org Cc: Cliff Sojournermailto:cls@employees.org Subject: Re: [44net] DN42 for 44net?
Unfortunately, compression is considered a type of encryption so also a no no over the air. Apparently, even a common well-documented type such as ZIP.
We could run SSL with a NULL cipher over the air. Not much gain from that, though, because the HMAC is made to detect small number of bit errors, but not at the rates we likely see over the air. And it is detection only, no correction.
Cliff K6CLS CM87
On December 3, 2021 10:42:56 AM PST, "Tim Požar via 44Net" 44net@mailman.ampr.org wrote:
There have been two attempts to get the FCC to allow encryption in Part 97. RM-11699 in 2013 and RM-11831 in 2019. Both have been dismissed by the FCC. Please read these petitions and you will see that encryption is not allowed.
Tim
On 12/3/21 10:32 AM, Dave Gingrich via 44Net wrote:
That is referencing phone ops, transmitting music, and coded words to hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today, that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote:
Please refer to § 97.113(a)(4) Prohibited transmissions...
(4) [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein [...]
Tim
On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote:
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world. Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions. — Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Please point to the reference that says compression is encryption.
Tim
On 12/3/21 11:10 AM, Cliff Sojourner via 44Net wrote:
Unfortunately, compression is considered a type of encryption so also a no no over the air. Apparently, even a common well-documented type such as ZIP.
We could run SSL with a NULL cipher over the air. Not much gain from that, though, because the HMAC is made to detect small number of bit errors, but not at the rates we likely see over the air. And it is detection only, no correction.
Cliff K6CLS CM87
On December 3, 2021 10:42:56 AM PST, "Tim Požar via 44Net" 44net@mailman.ampr.org wrote:
There have been two attempts to get the FCC to allow encryption in Part 97. RM-11699 in 2013 and RM-11831 in 2019. Both have been dismissed by the FCC. Please read these petitions and you will see that encryption is not allowed.
Tim
On 12/3/21 10:32 AM, Dave Gingrich via 44Net wrote:
That is referencing phone ops, transmitting music, and coded words to hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today, that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote:
Please refer to § 97.113(a)(4) Prohibited transmissions...
(4) [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein [...]
Tim
On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote:
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world. Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions. — Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
They are on the same spectrum of methods to remove the entropy of a message. Basic cryptography.
What compression techniques are we presently allowed to use over the air?
Cliff K6CLS CM87
On December 3, 2021 11:38:22 AM PST, "Tim Požar" pozar@lns.com wrote:
Please point to the reference that says compression is encryption.
Tim
On 12/3/21 11:10 AM, Cliff Sojourner via 44Net wrote:
Unfortunately, compression is considered a type of encryption so also a no no over the air. Apparently, even a common well-documented type such as ZIP.
We could run SSL with a NULL cipher over the air. Not much gain from that, though, because the HMAC is made to detect small number of bit errors, but not at the rates we likely see over the air. And it is detection only, no correction.
Cliff K6CLS CM87
On December 3, 2021 10:42:56 AM PST, "Tim Požar via 44Net" 44net@mailman.ampr.org wrote:
There have been two attempts to get the FCC to allow encryption in Part 97. RM-11699 in 2013 and RM-11831 in 2019. Both have been dismissed by the FCC. Please read these petitions and you will see that encryption is not allowed.
Tim
On 12/3/21 10:32 AM, Dave Gingrich via 44Net wrote:
That is referencing phone ops, transmitting music, and coded words to hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today, that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote:
Please refer to § 97.113(a)(4) Prohibited transmissions...
(4) [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein [...]
Tim
On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote:
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world. Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions. — Dave K9DC > On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote: > > Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. > Networks can and do have encryption as long as relay over air has information in the clear. > > Adam Lewis > KC7GDY _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Any that don’t require a key to decompress, ie anything where you don’t enter a password to compress it. Else it’s not encryption.
Tom
On Fri, 3 Dec 2021 at 19:54, Cliff Sojourner via 44Net < 44net@mailman.ampr.org> wrote:
They are on the same spectrum of methods to remove the entropy of a message. Basic cryptography.
What compression techniques are we presently allowed to use over the air?
Cliff K6CLS CM87
On December 3, 2021 11:38:22 AM PST, "Tim Požar" pozar@lns.com wrote:
Please point to the reference that says compression is encryption.
Tim
On 12/3/21 11:10 AM, Cliff Sojourner via 44Net wrote:
Unfortunately, compression is considered a type of encryption so also
a no no over the air. Apparently, even a common well-documented type such as ZIP.
We could run SSL with a NULL cipher over the air. Not much gain from
that, though, because the HMAC is made to detect small number of bit errors, but not at the rates we likely see over the air. And it is detection only, no correction.
Cliff K6CLS CM87
On December 3, 2021 10:42:56 AM PST, "Tim Požar via 44Net" <
44net@mailman.ampr.org> wrote:
There have been two attempts to get the FCC to allow encryption in Part 97. RM-11699 in 2013 and RM-11831 in 2019. Both have been dismissed
by
the FCC. Please read these petitions and you will see that encryption is not allowed.
Tim
On 12/3/21 10:32 AM, Dave Gingrich via 44Net wrote:
That is referencing phone ops, transmitting music, and coded words to
hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today,
that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote:
Please refer to § 97.113(a)(4) Prohibited transmissions...
(4) [...] messages encoded for the purpose of obscuring their
meaning, except as otherwise provided herein [...]
Tim
On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote: > Please point out where the "the USA encryption restriction” over
radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world.
> Encryption over RF links has not been illegal for years, at least
in .US. I can’t speak for other jurisdictions.
> — > Dave K9DC >> On Dec 3, 2021, at 11:23, air gapped via 44Net <
44net@mailman.ampr.org> wrote:
>> >> Something to keep in mind: the USA encryption restriction only
applies to traffic going over the air.
>> Networks can and do have encryption as long as relay over air has
information in the clear.
>> >> Adam Lewis >> KC7GDY > _________________________________________ > 44Net mailing list > 44Net@mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Ok... How about zip? Technically the message body is not decipherable without the dictionary. So that is like a "key".
Practically though, the dictionary and body are always kept together. So, great for block compression.
How would you make a stream compressor with those pieces?
On December 3, 2021 12:02:37 PM PST, Tom M0LTE via 44Net 44net@mailman.ampr.org wrote:
Any that don’t require a key to decompress, ie anything where you don’t enter a password to compress it. Else it’s not encryption.
Tom
On Fri, 3 Dec 2021 at 19:54, Cliff Sojourner via 44Net < 44net@mailman.ampr.org> wrote:
They are on the same spectrum of methods to remove the entropy of a message. Basic cryptography.
What compression techniques are we presently allowed to use over the air?
Cliff K6CLS CM87
On December 3, 2021 11:38:22 AM PST, "Tim Požar" pozar@lns.com wrote:
Please point to the reference that says compression is encryption.
Tim
On 12/3/21 11:10 AM, Cliff Sojourner via 44Net wrote:
Unfortunately, compression is considered a type of encryption so also
a no no over the air. Apparently, even a common well-documented type such as ZIP.
We could run SSL with a NULL cipher over the air. Not much gain from
that, though, because the HMAC is made to detect small number of bit errors, but not at the rates we likely see over the air. And it is detection only, no correction.
Cliff K6CLS CM87
On December 3, 2021 10:42:56 AM PST, "Tim Požar via 44Net" <
44net@mailman.ampr.org> wrote:
There have been two attempts to get the FCC to allow encryption in Part 97. RM-11699 in 2013 and RM-11831 in 2019. Both have been dismissed
by
the FCC. Please read these petitions and you will see that encryption is not allowed.
Tim
On 12/3/21 10:32 AM, Dave Gingrich via 44Net wrote:
That is referencing phone ops, transmitting music, and coded words to
hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today,
that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
> On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote: > > Please refer to § 97.113(a)(4) Prohibited transmissions... > > (4) [...] messages encoded for the purpose of obscuring their
meaning, except as otherwise provided herein [...]
> > Tim > > On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote: >> Please point out where the "the USA encryption restriction” over
radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world.
>> Encryption over RF links has not been illegal for years, at least
in .US. I can’t speak for other jurisdictions.
>> — >> Dave K9DC >>> On Dec 3, 2021, at 11:23, air gapped via 44Net <
44net@mailman.ampr.org> wrote:
>>> >>> Something to keep in mind: the USA encryption restriction only
applies to traffic going over the air.
>>> Networks can and do have encryption as long as relay over air has
information in the clear.
>>> >>> Adam Lewis >>> KC7GDY >> _________________________________________ >> 44Net mailing list >> 44Net@mailman.ampr.org >> https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
FT8 uses compression.
Ron W6RZ
On 12/3/21 11:53 AM, Cliff Sojourner via 44Net wrote:
They are on the same spectrum of methods to remove the entropy of a message. Basic cryptography.
What compression techniques are we presently allowed to use over the air?
Cliff K6CLS CM87
On December 3, 2021 11:38:22 AM PST, "Tim Požar" pozar@lns.com wrote:
Please point to the reference that says compression is encryption.
Tim
On 12/3/21 11:10 AM, Cliff Sojourner via 44Net wrote:
Unfortunately, compression is considered a type of encryption so also a no no over the air. Apparently, even a common well-documented type such as ZIP.
We could run SSL with a NULL cipher over the air. Not much gain from that, though, because the HMAC is made to detect small number of bit errors, but not at the rates we likely see over the air. And it is detection only, no correction.
Cliff K6CLS CM87
On December 3, 2021 10:42:56 AM PST, "Tim Požar via 44Net" 44net@mailman.ampr.org wrote:
There have been two attempts to get the FCC to allow encryption in Part 97. RM-11699 in 2013 and RM-11831 in 2019. Both have been dismissed by the FCC. Please read these petitions and you will see that encryption is not allowed.
Tim
On 12/3/21 10:32 AM, Dave Gingrich via 44Net wrote:
That is referencing phone ops, transmitting music, and coded words to hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today, that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote:
Please refer to § 97.113(a)(4) Prohibited transmissions...
(4) [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein [...]
Tim
On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote: > Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world. > Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions. > — > Dave K9DC >> On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote: >> >> Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. >> Networks can and do have encryption as long as relay over air has information in the clear. >> >> Adam Lewis >> KC7GDY > _________________________________________ > 44Net mailing list > 44Net@mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Compression is not encryption. You can use any known compression you want as you are not obfuscating the data with a method that can't be reversed w/o a key exchange/passphrase/etc.
For instance, I can capture the compressed data stream and decompress it later w/o knowing a secret. It may take a couple of tries to figure out the compression scheme, but I am not stopped due to a lack of a key.
I would love to see an authoritative reference to say compression is encryption. If you find one, please pass it along.
Tim
On 12/3/21 12:27 PM, Ron Economos via 44Net wrote:
FT8 uses compression.
Ron W6RZ
On 12/3/21 11:53 AM, Cliff Sojourner via 44Net wrote:
They are on the same spectrum of methods to remove the entropy of a message. Basic cryptography.
What compression techniques are we presently allowed to use over the air?
Cliff K6CLS CM87
On December 3, 2021 11:38:22 AM PST, "Tim Požar" pozar@lns.com wrote:
Please point to the reference that says compression is encryption.
Tim
On 12/3/21 11:10 AM, Cliff Sojourner via 44Net wrote:
Unfortunately, compression is considered a type of encryption so also a no no over the air. Apparently, even a common well-documented type such as ZIP.
We could run SSL with a NULL cipher over the air. Not much gain from that, though, because the HMAC is made to detect small number of bit errors, but not at the rates we likely see over the air. And it is detection only, no correction.
Cliff K6CLS CM87
On December 3, 2021 10:42:56 AM PST, "Tim Požar via 44Net" 44net@mailman.ampr.org wrote:
There have been two attempts to get the FCC to allow encryption in Part 97. RM-11699 in 2013 and RM-11831 in 2019. Both have been dismissed by the FCC. Please read these petitions and you will see that encryption is not allowed.
Tim
On 12/3/21 10:32 AM, Dave Gingrich via 44Net wrote:
That is referencing phone ops, transmitting music, and coded words to hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today, that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
> On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote: > > Please refer to § 97.113(a)(4) Prohibited transmissions... > > (4) [...] messages encoded for the purpose of obscuring their > meaning, except as otherwise provided herein [...] > > Tim > > On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote: >> Please point out where the "the USA encryption restriction” over >> radio links, is documented. After all, D-Star radios use a >> proprietary codec. Heck even if you access https://ampr.org/ >> over a radio link, the connection is SSL encrypted, as are >> nearly all web sites in the world. >> Encryption over RF links has not been illegal for years, at >> least in .US. I can’t speak for other jurisdictions. >> — >> Dave K9DC >>> On Dec 3, 2021, at 11:23, air gapped via 44Net >>> 44net@mailman.ampr.org wrote: >>> >>> Something to keep in mind: the USA encryption restriction only >>> applies to traffic going over the air. >>> Networks can and do have encryption as long as relay over air >>> has information in the clear. >>> >>> Adam Lewis >>> KC7GDY >> _________________________________________ >> 44Net mailing list >> 44Net@mailman.ampr.org >> https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
The FT8 scheme is well known, documented, and has readily available decoders, and transmissions are clearly marked as such.
Meets the FCC criteria so it's allowed.
On December 3, 2021 12:27:53 PM PST, Ron Economos via 44Net 44net@mailman.ampr.org wrote:
FT8 uses compression.
Ron W6RZ
On 12/3/21 11:53 AM, Cliff Sojourner via 44Net wrote:
They are on the same spectrum of methods to remove the entropy of a message. Basic cryptography.
What compression techniques are we presently allowed to use over the air?
Cliff K6CLS CM87
On December 3, 2021 11:38:22 AM PST, "Tim Požar" pozar@lns.com wrote:
Please point to the reference that says compression is encryption.
Tim
On 12/3/21 11:10 AM, Cliff Sojourner via 44Net wrote:
Unfortunately, compression is considered a type of encryption so also a no no over the air. Apparently, even a common well-documented type such as ZIP.
We could run SSL with a NULL cipher over the air. Not much gain from that, though, because the HMAC is made to detect small number of bit errors, but not at the rates we likely see over the air. And it is detection only, no correction.
Cliff K6CLS CM87
On December 3, 2021 10:42:56 AM PST, "Tim Požar via 44Net" 44net@mailman.ampr.org wrote:
There have been two attempts to get the FCC to allow encryption in Part 97. RM-11699 in 2013 and RM-11831 in 2019. Both have been dismissed by the FCC. Please read these petitions and you will see that encryption is not allowed.
Tim
On 12/3/21 10:32 AM, Dave Gingrich via 44Net wrote:
That is referencing phone ops, transmitting music, and coded words to hide meaning. It certainly does not include encryption, using standards based tools, such as SSH or SSL. I was using those methods over the radio in the 1990s. IOW, that whole paragraph speaks to the purpose of the transmission, not the traffic it generates.
It will be near impossible to establish any type of network today, that does not carry traffic that is not encrypted in some fashion. If that is a requirement, we'd best just give up and shut off our radios.
— Dave K9DC
> On Dec 3, 2021, at 12:50, Tim Požar pozar@lns.com wrote: > > Please refer to § 97.113(a)(4) Prohibited transmissions... > > (4) [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein [...] > > Tim > > On 12/3/21 9:45 AM, Dave Gingrich via 44Net wrote: >> Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world. >> Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions. >> — >> Dave K9DC >>> On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote: >>> >>> Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. >>> Networks can and do have encryption as long as relay over air has information in the clear. >>> >>> Adam Lewis >>> KC7GDY >> _________________________________________ >> 44Net mailing list >> 44Net@mailman.ampr.org >> https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On Fri, 3 Dec 2021, Cliff Sojourner via 44Net wrote:
The FT8 scheme is well known, documented, and has readily available decoders, and transmissions are clearly marked as such.
VARA on the other hand... I'm waiting for a protocol specification document that defines exactly how the over-the-air handshake is performed, and the internal protocol.
-- Kris Kirby, KE4AHR Disinformation Architect, Systems Mangler, & Network Mismanager
Yeah... Exactly...
On December 3, 2021 4:08:07 PM PST, Kris Kirby via 44Net 44net@mailman.ampr.org wrote:
On Fri, 3 Dec 2021, Cliff Sojourner via 44Net wrote:
The FT8 scheme is well known, documented, and has readily available decoders, and transmissions are clearly marked as such.
VARA on the other hand... I'm waiting for a protocol specification document that defines exactly how the over-the-air handshake is performed, and the internal protocol.
-- Kris Kirby, KE4AHR Disinformation Architect, Systems Mangler, & Network Mismanager _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
It depends on which country we are talking about. Here in the United States, there is no mention of "encryption" in Part 97. It only mentions if your intent is to obscure the meaning of the message then it's forbidden.
You'll discover there is a very thin line between compression and encryption. And generally that boils down to public documentation and intentions. For example: there are ways to use SSH with null ciphers. You could also announce your key in the clear.
In the early days of HSMM before ad-hoc Mesh techniques and out of Part 15 space channels, there was a need to keep unlicensed devices from interacting with ham (part 97) ones. They used a published key to achieve this.
It boils down to intent. For example; if you're talking in pig latin on a repeater solely to keep others from knowing what you are talking about with your friend, that my friend is also forbidden and would be the same as this commonly used encryption notion that simply does not exist as a word in our US regulations.
It would be nice in my opinion if Part 97 took a firmer stance on publicly documented techniques. As those help move the hobby forward.
As for Amprnet (ARDC) making some sort of statement on traffic over the internet, I don't feel that is necessary. It's much too complicated with all the various countries involved and should be up to the folks who do interconnect over the air stuff to the internet. Some prefer not having to decapsulate when passing the traffic over RF. If encrypted traffic over the internet is important to you, find like minded folks and coordinate something that does that.
I do think using the LoTW certificates for the Portal login and user verification does make sense from a spam and abuse perspective.
On Fri, Dec 3, 2021 at 1:55 PM Cliff Sojourner via 44Net 44net@mailman.ampr.org wrote:
They are on the same spectrum of methods to remove the entropy of a message. Basic cryptography.
What compression techniques are we presently allowed to use over the air?
Cliff K6CLS CM87
Encoding is not encryption. You could decode D-STAR if you have the chip and everyone is free to decode the conversation. Kun
________________________________ From: 44Net 44net-bounces+dnwk=linkun.info@mailman.ampr.org on behalf of Dave Gingrich via 44Net 44net@mailman.ampr.org Sent: Friday, December 3, 2021 9:45 To: 44Net general discussion 44net@mailman.ampr.org Cc: Dave Gingrich dave@dcg.us Subject: Re: [44net] DN42 for 44net?
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world.
Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions.
— Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
DStar is not a good example for your point. AMBE codec was patent encumbered for many years, not completely documented, so technically unable to be easily decoded.
I'm aware of one open source implementation of it, don't know if it is used at all, or how well it works.
Remember, PSK31 was not allowed by the FCC, until an open source implementation became commonly available. They key was documenting Vari-code. It's not difficult, or tricky, it is just a Huffman encoding such as used by Morse Code! So the PSK31 experience is the model for getting acceptance of a not-human-readable mode on amateur frequencies.
Pactor 4 is in that situation now. Proprietary codec, patent encumbered, not publicly documented... So should not be allowed on amateur frequencies; Commercial frequencies, ok.
I'm not sure about VARA, anyone know?
On December 3, 2021 9:58:23 AM PST, KUN LIN via 44Net 44net@mailman.ampr.org wrote:
Encoding is not encryption. You could decode D-STAR if you have the chip and everyone is free to decode the conversation. Kun
From: 44Net 44net-bounces+dnwk=linkun.info@mailman.ampr.org on behalf of Dave Gingrich via 44Net 44net@mailman.ampr.org Sent: Friday, December 3, 2021 9:45 To: 44Net general discussion 44net@mailman.ampr.org Cc: Dave Gingrich dave@dcg.us Subject: Re: [44net] DN42 for 44net?
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world.
Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions.
— Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Speaking for myself,
Encoding cannot be seen as encryption in any way. There are many ways of encoding a messsage. And there is many type of message that can only be sent by encoding. You cannot send an image without first encoding it in tone. You cannot send a numerical value without sending it as a tone scheme that can be decoded by a circuit. You cannot send a text without encoding either by voice (transforming letters/words/numbers to sounds) or by a digital mode ( morse being a digital mode) You cannot send digitaly compressed voice without encoding it in a way to send digital information.
All of those action are accepted by the FCC.
Encryption is making sure no one but the intended receipient of a message that have a method of removing the encryption of the message can receive it properly. If everyone can remove the encryption, it is in fact non encrypted.
Microsoft use that as their explanation of encryption. What exactly are encryption? Encryption is the process of translating plain text data (plaintext) into something that appears to be random and meaningless (ciphertext). ... A symmetric key is used during both the encryption and decryption processes. To decrypt a particular piece of ciphertext, the key that was used to encrypt the data must be used.
Morse is a way to send plain text data into something meaninless for anyone that does not know the code ( the key) .
Using a language that no one know is a form of encryption. But from what I do know of the FCC law, someone only need to ID in english to be ok while talking in any other language.
And at last, there is no provision in the FCC law for ham radio that deal with something that is Over The Air. (OTA) Also, If we follow all the rules for the ISM band for transmitting our data, being ham radio stuff or anything else, the FCC cannot do much stuff.
Yeah some will say, but it that case it is not ham radio. Simply put, You are right. But we use the airwaves that are both assigned to the ISM and Ham band. So we use our bands.
Pierre VE2PF
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Cliff Sojourner via 44Net 44net@mailman.ampr.org Envoyé : 3 décembre 2021 14:44 À : 44Net general discussion Cc : Cliff Sojourner Objet : Re: [44net] DN42 for 44net?
DStar is not a good example for your point. AMBE codec was patent encumbered for many years, not completely documented, so technically unable to be easily decoded.
I'm aware of one open source implementation of it, don't know if it is used at all, or how well it works.
Remember, PSK31 was not allowed by the FCC, until an open source implementation became commonly available. They key was documenting Vari-code. It's not difficult, or tricky, it is just a Huffman encoding such as used by Morse Code! So the PSK31 experience is the model for getting acceptance of a not-human-readable mode on amateur frequencies.
Pactor 4 is in that situation now. Proprietary codec, patent encumbered, not publicly documented... So should not be allowed on amateur frequencies; Commercial frequencies, ok.
I'm not sure about VARA, anyone know?
On December 3, 2021 9:58:23 AM PST, KUN LIN via 44Net 44net@mailman.ampr.org wrote:
Encoding is not encryption. You could decode D-STAR if you have the chip and everyone is free to decode the conversation. Kun
From: 44Net 44net-bounces+dnwk=linkun.info@mailman.ampr.org on behalf of Dave Gingrich via 44Net 44net@mailman.ampr.org Sent: Friday, December 3, 2021 9:45 To: 44Net general discussion 44net@mailman.ampr.org Cc: Dave Gingrich dave@dcg.us Subject: Re: [44net] DN42 for 44net?
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world.
Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions.
— Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
oups typo.
there is no provision in the FCC law for ham radio that deal with something that is Over The Air. should have been read as
there is no provision in the FCC law for ham radio that deal with something that is NOT Over The Air.
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de pete M via 44Net 44net@mailman.ampr.org Envoyé : 3 décembre 2021 16:24 À : 44Net general discussion Cc : pete M Objet : Re: [44net] DN42 for 44net?
Speaking for myself,
Encoding cannot be seen as encryption in any way. There are many ways of encoding a messsage. And there is many type of message that can only be sent by encoding. You cannot send an image without first encoding it in tone. You cannot send a numerical value without sending it as a tone scheme that can be decoded by a circuit. You cannot send a text without encoding either by voice (transforming letters/words/numbers to sounds) or by a digital mode ( morse being a digital mode) You cannot send digitaly compressed voice without encoding it in a way to send digital information.
All of those action are accepted by the FCC.
Encryption is making sure no one but the intended receipient of a message that have a method of removing the encryption of the message can receive it properly. If everyone can remove the encryption, it is in fact non encrypted.
Microsoft use that as their explanation of encryption. What exactly are encryption? Encryption is the process of translating plain text data (plaintext) into something that appears to be random and meaningless (ciphertext). ... A symmetric key is used during both the encryption and decryption processes. To decrypt a particular piece of ciphertext, the key that was used to encrypt the data must be used.
Morse is a way to send plain text data into something meaninless for anyone that does not know the code ( the key) .
Using a language that no one know is a form of encryption. But from what I do know of the FCC law, someone only need to ID in english to be ok while talking in any other language.
And at last, there is no provision in the FCC law for ham radio that deal with something that is Over The Air. (OTA) Also, If we follow all the rules for the ISM band for transmitting our data, being ham radio stuff or anything else, the FCC cannot do much stuff.
Yeah some will say, but it that case it is not ham radio. Simply put, You are right. But we use the airwaves that are both assigned to the ISM and Ham band. So we use our bands.
Pierre VE2PF
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Cliff Sojourner via 44Net 44net@mailman.ampr.org Envoyé : 3 décembre 2021 14:44 À : 44Net general discussion Cc : Cliff Sojourner Objet : Re: [44net] DN42 for 44net?
DStar is not a good example for your point. AMBE codec was patent encumbered for many years, not completely documented, so technically unable to be easily decoded.
I'm aware of one open source implementation of it, don't know if it is used at all, or how well it works.
Remember, PSK31 was not allowed by the FCC, until an open source implementation became commonly available. They key was documenting Vari-code. It's not difficult, or tricky, it is just a Huffman encoding such as used by Morse Code! So the PSK31 experience is the model for getting acceptance of a not-human-readable mode on amateur frequencies.
Pactor 4 is in that situation now. Proprietary codec, patent encumbered, not publicly documented... So should not be allowed on amateur frequencies; Commercial frequencies, ok.
I'm not sure about VARA, anyone know?
On December 3, 2021 9:58:23 AM PST, KUN LIN via 44Net 44net@mailman.ampr.org wrote:
Encoding is not encryption. You could decode D-STAR if you have the chip and everyone is free to decode the conversation. Kun
From: 44Net 44net-bounces+dnwk=linkun.info@mailman.ampr.org on behalf of Dave Gingrich via 44Net 44net@mailman.ampr.org Sent: Friday, December 3, 2021 9:45 To: 44Net general discussion 44net@mailman.ampr.org Cc: Dave Gingrich dave@dcg.us Subject: Re: [44net] DN42 for 44net?
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world.
Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions.
— Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Pactor 4 is NOT in that situation. On HF, you are limited to 300 baud. Pactor 4 is way faster than 300 baud. Kun
________________________________ From: 44Net 44net-bounces+dnwk=linkun.info@mailman.ampr.org on behalf of Cliff Sojourner via 44Net 44net@mailman.ampr.org Sent: Friday, December 3, 2021 11:44 To: 44Net general discussion 44net@mailman.ampr.org Cc: Cliff Sojourner cls@employees.org Subject: Re: [44net] DN42 for 44net?
DStar is not a good example for your point. AMBE codec was patent encumbered for many years, not completely documented, so technically unable to be easily decoded.
I'm aware of one open source implementation of it, don't know if it is used at all, or how well it works.
Remember, PSK31 was not allowed by the FCC, until an open source implementation became commonly available. They key was documenting Vari-code. It's not difficult, or tricky, it is just a Huffman encoding such as used by Morse Code! So the PSK31 experience is the model for getting acceptance of a not-human-readable mode on amateur frequencies.
Pactor 4 is in that situation now. Proprietary codec, patent encumbered, not publicly documented... So should not be allowed on amateur frequencies; Commercial frequencies, ok.
I'm not sure about VARA, anyone know?
On December 3, 2021 9:58:23 AM PST, KUN LIN via 44Net 44net@mailman.ampr.org wrote:
Encoding is not encryption. You could decode D-STAR if you have the chip and everyone is free to decode the conversation. Kun
From: 44Net 44net-bounces+dnwk=linkun.info@mailman.ampr.org on behalf of Dave Gingrich via 44Net 44net@mailman.ampr.org Sent: Friday, December 3, 2021 9:45 To: 44Net general discussion 44net@mailman.ampr.org Cc: Dave Gingrich dave@dcg.us Subject: Re: [44net] DN42 for 44net?
Please point out where the "the USA encryption restriction” over radio links, is documented. After all, D-Star radios use a proprietary codec. Heck even if you access https://ampr.org/ over a radio link, the connection is SSL encrypted, as are nearly all web sites in the world.
Encryption over RF links has not been illegal for years, at least in .US. I can’t speak for other jurisdictions.
— Dave K9DC
On Dec 3, 2021, at 11:23, air gapped via 44Net 44net@mailman.ampr.org wrote:
Something to keep in mind: the USA encryption restriction only applies to traffic going over the air. Networks can and do have encryption as long as relay over air has information in the clear.
Adam Lewis KC7GDY
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
I don't think the IPIP tunnel 44NET running is standard IPIP tunnel. It has a lot of none standard parts. Kun
________________________________ From: 44Net 44net-bounces+dnwk=linkun.info@mailman.ampr.org on behalf of Kristjan Komloši via 44Net 44net@mailman.ampr.org Sent: Thursday, December 2, 2021 14:38 To: 44net@mailman.ampr.org 44net@mailman.ampr.org Cc: Kristjan Komloši kristjan@piskot.si Subject: Re: [44net] DN42 for 44net?
I've been working with BGP, Unix-like OS, and networks a decent amount, so here's my two cents.
IPIP has a significant advantage that it's dead simple to operate and that it works on most Unix-like operating systems (and cisco routers), however it's a very rudimentary protocol, inferior to even GRE. Considering that hamradio doesn't allow encryption, OpenVPN and Wireguard are off the table. What I think would be cooler is if we tried to run local tunneling services. I think we have a lot of people in our community who are well-educated in the radio part of AMPRnet, and others who are well-educated in the internet part of it. Localizing the AMPRnet tunnels would bring local communities closer together.
Another point maybe worth considering is dropping RIP44 altogether (because it's a non standard protocol) and replacing it with a BGP route reflector. Then a transition to a more DN42-like network could be easier because we wouldn't need to invent our own standards.
73
On 2. 12. 21 22:45, KUN LIN via 44Net wrote:
I feel like 44net need to move on from existing customized IPIP tunnel and onto something more modern. Existing tunnel could be kept for backward compatibility. Kun
From: 44Net 44net-bounces+dnwk=linkun.info@mailman.ampr.org on behalf of John Burwell via 44Net 44net@mailman.ampr.org Sent: Thursday, December 2, 2021 13:01 To: 44net@mailman.ampr.org 44net@mailman.ampr.org Cc: John Burwell john@b-wells.us Subject: Re: [44net] DN42 for 44net?
Thanks for sharing. I see this has been around a while, but I hadn’t run
into it myself yet.
Apple is currently doing something like this with IPSEC and IPv6 for iCloud users; pretty much any iCloud user is always on a private VPN with all their other iCloud devices. And there are commercial enterprise SD-WAN products and cloud providers that offer a similar approach for SMBs and branch offices. Azure and AWS offer almost exactly this between virtual networks, data centers, and regions, down to the private ASNs.
It’s nice to see a project built on open standards for the express purpose of playing with it and learning about it. Seems very much like something 44net could benefit from studying carefully.
From: KUN LIN dnwk@linkun.info
To: "44net@mailman.ampr.org" 44net@mailman.ampr.org Cc: Bcc: Date: Thu, 2 Dec 2021 18:48:49 +0000 Subject: [44net] DN42 for 44net?
Just discover this new thing where it will create mesh networks and even BGP via VPN tunnels. This maybe an interesting way for 44net to considering implement.
dn42 is a big dynamic VPN< https://en.wikipedia.org/wiki/Virtual_private_network%3E, which employs Internet technologies (BGPhttps://en.wikipedia.org/wiki/Bgp, whois database, DNShttps://en.wikipedia.org/wiki/Domain_Name_System, etc). Participants connect to each other using network tunnels (GRE< https://dn42.dev/howto/GRE-on-FreeBSD%3E, OpenVPN< https://dn42.dev/howto/openvpn%3E, WireGuard< https://dn42.dev/howto/wireguard%3E, Tinchttps://dn42.dev/howto/tinc, IPsechttps://dn42.dev/howto/IPsec-with-PublicKeys) and exchange routes thanks to the Border Gateway Protocol. Network addresses are assigned in the 172.20.0.0/14 range and private AS numbers are used (see registry< https://dn42.dev/services/Whois%3E) as well as IPv6 addresses from the ULA-Range (fd00::/8) –
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On Thu, 2 Dec 2021, Kristjan Komlo?i via 44Net wrote:
Considering that hamradio doesn't allow encryption, OpenVPN and Wireguard are off the table. What I think would be cooler is if we tried
Encryption is not allowed _over the air_. There is nothing wrong with running encryption over the public internet or between devices or over a NAT edge. It has to be GRE or another VPN method with the encryption turned off. OpenVPN supports an encryption of "none". Ubiquiti's EdgeOS no longer allows that to be passed to OpenVPN however. It's important to note that turning off encryption opens up the possibility of replay attacks and other misbehavior. Defense in depth should always be part of the implementation. Use in conjuction with firewall rules.
-- Kris Kirby, KE4AHR Disinformation Architect, Systems Mangler, & Network Mismanager
You are correct. You just literally described what my company does. We create DTLS tunnels from an on-Prem device, or virtual appliances in AWS / Azure. We also support IPSEC imto our cloud as well.
We will consume and share BGP routes to interop with customer networks that have other connections outside of our control.
This isn’t that out of the ordinary.
On Thu, Dec 2, 2021 at 4:04 PM John Burwell via 44Net < 44net@mailman.ampr.org> wrote:
Thanks for sharing. I see this has been around a while, but I hadn’t run
into it myself yet.
Apple is currently doing something like this with IPSEC and IPv6 for iCloud users; pretty much any iCloud user is always on a private VPN with all their other iCloud devices. And there are commercial enterprise SD-WAN products and cloud providers that offer a similar approach for SMBs and branch offices. Azure and AWS offer almost exactly this between virtual networks, data centers, and regions, down to the private ASNs.
It’s nice to see a project built on open standards for the express purpose of playing with it and learning about it. Seems very much like something 44net could benefit from studying carefully.
From: KUN LIN dnwk@linkun.info
To: "44net@mailman.ampr.org" 44net@mailman.ampr.org Cc: Bcc: Date: Thu, 2 Dec 2021 18:48:49 +0000 Subject: [44net] DN42 for 44net?
Just discover this new thing where it will create mesh networks and even BGP via VPN tunnels. This maybe an interesting way for 44net to
considering
implement.
dn42 is a big dynamic VPN< https://en.wikipedia.org/wiki/Virtual_private_network%3E, which employs Internet technologies (BGPhttps://en.wikipedia.org/wiki/Bgp, whois database, DNShttps://en.wikipedia.org/wiki/Domain_Name_System, etc). Participants connect to each other using network tunnels (GRE< https://dn42.dev/howto/GRE-on-FreeBSD%3E, OpenVPN< https://dn42.dev/howto/openvpn%3E, WireGuard< https://dn42.dev/howto/wireguard%3E, Tinchttps://dn42.dev/howto/tinc, IPsechttps://dn42.dev/howto/IPsec-with-PublicKeys) and exchange routes thanks to the Border Gateway Protocol. Network addresses are assigned in the 172.20.0.0/14 range and private AS numbers are used (see registry< https://dn42.dev/services/Whois%3E) as well as IPv6 addresses from the ULA-Range (fd00::/8) –
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
-
air gapped -
Cliff Sojourner -
Craig Brauckmiller -
Dave Gingrich -
John Burwell -
Keaton VE5LPL -
Kris Kirby -
Kristjan Komloši -
KUN LIN -
pete M -
Rob PE1CHL -
Ron Economos -
Steve L -
Tim Požar -
Tom M0LTE