While planning a local mesh, I planned having files shared from an RPi3, and some applications, such as a web server, chat server, and a relay module.
How does the Ham community interpret FCC regulations regarding secure protocols over Mesh? I'm used to using self-signed certs, and standard user/group security on Linux and other systems.
Thanks, Charlie KØTAN
You are here
What protocols allowed on AREDN / Mesh? HTTPS, SSH, etc?
Thu, 04/13/2017 - 01:10
#1
k0tan
What protocols allowed on AREDN / Mesh? HTTPS, SSH, etc?
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
My personal interpretation is that they are generally not permissible, especially when an alternative exists that isn't encrypted (http vs https, telnet Vs ssh, ftp vs ftps, etc) then the adding of encryption would (to me) exist solely to "obscure the meaning" of the transmissions.
Self signed certs dont directly expose the private key needed for decryption, and even if you have the intial private key many protocols renegotiate the encryption key shortly after the initial connection is established meaning no one knows the real decryption key for the cycle unless you specifically log the negotiated key and publish it.
If it's argued that it's an unspecified digitial code and the protocol is fully published (e.g. Http with TLS private key blah) as the reason to allow it then we hit the question "why bother doing it that way and adding extra bureaucracy when an HTTP session would do it anyways"
Personaly I avoid any encrypted traffic over the mesh. I've yet to find anything that couldn't conceivably be done without encryption. Internet has worked for decades with encryptionnonly used to secure the most critical of transmissions, its only recently (5-10 years) "encrypt everything" has become common on the global internet.
As for application-level encryption, still mostly no. The FCC has informally said it's ok to use SSH to manage a server over the mesh, but I wouldn't bet my license on it. So you have a few options for node/server control: One is to use Telnet. The nodes already have telnet servers built in. Another is to set up SSH with a 'none' cipher. The nodes do not natively support this, and the AREDN team decided it wasn't worth it. Or you could play the odds and hope you don't get a letter from the FCC.
The main reason I opt for the second option is because SSH has capabilities that Telnet doesn't, such as tunneling, passwordless auth, agent forwarding, X11 forwarding, et cetera.
As for HTTPS, there is not yet a significant good reason nor workaround. HTTP/2 is starting to come into being, and so far every implementation requires encryption. Its advantages for the mesh are mainly related to speed and bandwidth, which would be especially helpful for cameras, but the encryption negates it. Do you have any specific needs for an encrypted protocol?
This is very interesting. Can you cite the source of this information please?
Actually not even the "should have known" part.
If a "reasonable individual would know reasonable should be expected to know" the defense wouldn't hold up.
In addition I recall an FCC case (though I don't have citation in front of me to verify it) where FCC went even further than that declaring basically "as a licensees Title 47 Part 97 license holder you are expected to comply with all of Title 47 and subject
to higher penalties for non compliance" (such as a part 15 device running out of spec )
Regarding using Part 15 channels (especially in 5.8 GHz)
Be advised that frequency is not the only issue at play here to make a node need to comply with Part 97 regs.
We are trying to link an outlying clinic to the main hospital for emcomm purposes but are finding out that their normal comms are weak and they would like to 'piggy back' on the mesh. I was thinking about running everything on Part 15 channels with the chance to reconfigure (change channel and ID on each node) in case of an emergency situation. Sounds like that is a no no.
In many cases what would normally be in a Part 15 devices the AREDN firmware leaves out (forcing you to stay in band, attempting to enforce power limits, avoiding frequency jumping/radar detection, etc)
There are a lot of regulations in Part 15 that I don't understand and can't speak to fully (like a regulation on multiple transmitters st the same site carrying the same data, does that mean exact same packets or does it mean same information like routing data going out two diffrent nodes, because that impacts how much power you can transmit per node)
Since the software is developed primarily for Amateur Radio that's where the feature set is geared to. If your an expert on Part 15 it could likely be configured on some channels to hit those requirements but it equally and very easily can be configured to not meet Part 15 requirements.
Couple examples of configurations we allow that are not Part 15 compliant:
Any channel below 149 we don't support DFS which is required for Part 15 but not for Part 97.
Any Channel above 166 is guaranteed out of Part 15 WIFI
Any Power level excursion (as noted a NanoStation M5 at full power pumps out around 8 times (2^3) the legal Part 15 Power levels )
Ultimatley the AREDN team isn't in my mind equipped to guarantee a Part 15 compliance, it's just so far outside our realm
of normal tasks. I know a decenent bit of Part 15 from years of reading, but as noted before there are parts that I have to say I'm not sure" on. There was talk ages ago about a Part 15 only mode but it got stricken largely for those reasons that we are not experts on Part 15 and that those of us involved at the time really wanted to focus on what we knew and who we were targeting (Amateur Radio Operators.)
1) Stand on part 15 compliance in the wifi linux driver for related settings AREDN has not changed: https://wireless.wiki.kernel.org/en/developers/regulatory
2) AREDN change #1: Do not use DFS channels below 149 (AREDN firmware will not automatically hop to another channel if weather radar pulses are detected).
3) AREDN change #2: Do not use channels above 165 to stay within part 15.407 (uni-3). (Don't try part 15.247 with another 25Mhz of space above 165--your equipment isn't likely certified under these different rules to begin with.)
4) Do your homework on the xmit power setting compliant with part 15 power limits. (This isn't an AREDN change, rather any WISP operator still needs to do this given various antenna gain options to choose from.)
5) Encryption is turned off in AREDN for the 802.11 adhoc connection, this feature is not avialable. However, under part 15 rules, you may transport https and other encrypted protocols (and/or deploy a vpn over this link for the serviced entity).
6) Hope there isn't too much channel contention, and link is still usable.
I don't believe we've made any other relevant changes to the linux driver to account for. Conrad is that correct, did I miss any?
Joe AE6XE
Probably the big one now that I think in it is that to my knowledge it is impermissible for a Part 15 device to be capable of going out of Band, by loading the AREDN firmware and confirming it into mesh mode it does permit out of band it's possible it negates any Part 15 operating ability of the hardware (even if not utilized. ) So may need to remove that configured code as well.
Part 15 is a VERY big set of regulations, I make no guarantee to any of it and I don't track what changes we do that may be Part 15 noncompliant as I'm focusing on Amatur Radio regulations when coding.
The current AREDN supported equipment is prior to newer fcc rules going into effect enforcing this channel lockdown, e.g. Mikrotik, devices certified under the same part 15 rules with the same out-of-part-15-channel ability meet FCC rules to operate legitimately. This may be a future issue for equipment manufactured under these newer fcc rules. But even then, I'm not convinced this is an issue for 3rd party FOSS's software enabling channels outside of part 15 would prevent part 15 usage.
The part 15 rules certify the 'equipment' and allow 3rd party FOSS to be loaded and maintain the equipment's certification to operate. The 3rd party FOSS is never 'certified' per se. The same equipment on 3rd party FOSS may or may not not pass certification--OpenWRT/LEDE's case--certification compliance is unknown. But it is apparently still permissible to operate. Of course if operations for whatever reason are outside part 15, one can be busted. I'm leaning on this reference: https://www.softwarefreedom.org/resources/2007/fcc-sdr-whitepaper.html
Joe AE6XE
Thanks for all the comments and info - seems like there might be a scenario where this would work - I will investigate further. I also remember reading about the out of 15 channel issue and the apparent flexibility. Thanks again to all
Ron K7OPA