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: 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(a)mailman.ampr.org> wrote:

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:

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:

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:

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(a)kagl.me On 2021-12-03 12:47 p.m., Tim Požar via 44Net wrote:

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:

Compression is never encryption!!!!!! Also change the subject. From: Cliff Sojourner via 44Net<mailto:44net@mailman.ampr.org> Sent: Friday, December 3, 2021 11:10 AM To: 44Net general discussion<mailto:44net@mailman.ampr.org> Cc: Cliff Sojourner<mailto: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" &lt;44net(a)mailman.ampr.org&gt; wrote: _________________________________________ 44Net mailing list 44Net(a)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" &lt;pozar(a)lns.com&gt; wrote:

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 &lt;44net(a)mailman.ampr.org&gt; wrote:

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:

On Fri, 3 Dec 2021, Cliff Sojourner via 44Net wrote: 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

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 &lt;44net(a)mailman.ampr.org&gt; wrote:

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 &lt;44net(a)mailman.ampr.org&gt; wrote:

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 &lt;44net-bounces+petem001=hotmail.com(a)mailman.ampr.org&gt; de la part de pete M via 44Net &lt;44net(a)mailman.ampr.org&gt; 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 &lt;44net-bounces+petem001=hotmail.com(a)mailman.ampr.org&gt; de la part de Cliff Sojourner via 44Net &lt;44net(a)mailman.ampr.org&gt; 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 &lt;44net(a)mailman.ampr.org&gt; wrote: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net(a)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 &lt;44net-bounces+dnwk=linkun.info(a)mailman.ampr.org&gt; on behalf of Kristjan Komloši via 44Net &lt;44net(a)mailman.ampr.org&gt; Sent: Thursday, December 2, 2021 14:38 To: 44net(a)mailman.ampr.org &lt;44net(a)mailman.ampr.org&gt; Cc: Kristjan Komloši &lt;kristjan(a)piskot.si&gt; 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: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net