<div dir="ltr">It appears that we're getting our layers mixed up.<div><br></div><div style>Phone patches to the pizza place are legitimate because the patching system itself is run by a licensed control operator. In this case, the RF link is layer 1 and the phone call is at least layer 3. The rules are for governing who gets to use layer 1 and for what purpose. It would be totally inappropriate for a pizza place to get a radio and camp on a frequency for the purpose of accepting orders. However, contacting another ham and asking them to order a pizza for you on their phone (or giving you an auto patch to do it yourself) is appropriate because the RF portion is still ham-to-ham, even if the message being relayed is not.</div>
<div style><br></div><div style>The same goes for "broadcasting". Your transmission must be intended for one or more hams, even if the message must be relayed by them to reach its final destination. If you knew the general public all had scanners tuned to a ham frequency, it would not be appropriate to create your own radio show meant for them.<br>
</div><div style><br></div><div style>Regarding AAA, I think we were also thinking about different layers. Securing the configuration of a network device and providing "security" for a network service (think SSL/TLS) is quite a bit different. I was referring to the latter.</div>
<div style><br></div><div style>Using IPSec(AH) is a very good idea.</div><div style><br></div><div style>I have high hopes that this will all work out. It sounds like so much fun, I can't contain myself! ;)</div><div style>
<br></div><div style>-Cory</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 20, 2013 at 9:55 PM, Bart Kus <span dir="ltr"><<a href="mailto:me@bartk.us" target="_blank">me@bartk.us</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>First of all, +1, Informative.<div class="im"><br>
<br>
On 2/20/2013 11:22 AM, Cory (NQ1E) wrote:<br>
</div></div><div class="im">
<blockquote type="cite">
<div dir="ltr">It's not just optimization. We have serious
restrictions on what type of content can be moved over our RF
links. Everyone who runs a device that transmits is responsible
for its operation. Luckily there is precedent here since each
node can be considered the same as a "digital packet repeater"
in historical context. In those cases, the repeater operator is
not held liable for illegal content relayed through them as long
as they take "reasonable measures" to limit it and when
discovered, stop it.
<div>
<br>
</div>
<div>While it's not preferable to get into the
distributed firewall business, it may be necessary if this
network carries traffic to or from the internet. If we had
another "reasonable" way to make sure only licensed hams were
able to originate content on the network, firewalls likely
wouldn't be needed.</div>
<div><br>
</div>
</div>
</blockquote>
<br></div>
I think of the case of an audio repeater phone patch. A ham can
call someone via hammy spectrum, but the return voice traffic may
not belong to a ham. This has been allowed in the past as fair use.<br>
<br>
Now if we tweak the scenario and say the phone call is originally
inbound from the repeater to the ham by a non-ham, but consists of
content which the ham (in control of hanging up) considers
appropriate as per the hammy rules of airwave content, should the
conversation be allowed to continue? :) My read on this is yes.
99% of the airtime will be the bidirectional content of the
conversation, just as it is in the outbound case. As long as this
content is in compliance with ham law, it ought not matter who sent
the original ring.<br>
<br>
The next step in this line of thinking is to translate the concepts
of the analog telephone call to that of opening a digital inbound
TCP session to a ham server. It's up to the ham who is hosting the
server to ensure that the content of such conversations complies
with ham rules. Hang up (TCP RST) the session if the content goes
outside the law. The role of HamWAN is simply to facilitate the
exchange of signals, and we're not held responsible (as per voice
repeater rules) should hams decide to break the rules of content.<br>
<br>
There is of course that little lingering issue of the initial
unsolicited ring in the analog world, or TCP SYN in the digital
world making its way onto hammy spectrum. I like to think HamWAN
could even set some useful precedent here, by delivering worthy
use-cases, and perhaps cause an eventual tweak to the official rules
to allow for short control messages ("I would like to talk") to be
sent over hammy spectrum by non-hammies.<br>
<br>
Another way of thinking about this inbound ring from non-hams is
that while the actual ring is received by ham equipment (repeater /
digital microwave router) on a non-hammy medium (telco / ISP
network), the hammy RF spectrum transmission from the repeater or
digital microwave router is not a signal relay, but rather a whole
new communication, initiated by a ham-licensed station (the repeater
and its owner) to inform the target ham of the presence of an
inbound message on the non-hammy medium, and is therefore ham2ham
traffic after all!<br>
<br>
We can do these legal mental gymnastics for a long time, but the
bottom line is unless someone actually complains and the FCC decides
to care, we should just go on and operate instead of shying away in
fear. If the practices are eventually ruled as illegal, we can
cease such operations easily by applying new firewall rules. I hope
it does not come to that as it would greatly stall the progress of
digital ham radio.<div class="im"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>In a somewhat related issue, there is also
precedent for hams using encrypted WiFi links with part 97
rules. Supposedly, it's only acceptable to encrypt when the
purpose is not to hide the content of your message. This
means that it's okay to run encryption as long you publish the
decryption keys so that they could be found by the public
(negating the point of using encryption in most cases).</div>
<div><br>
</div>
</div>
</blockquote>
<br></div>
Agreed, and I know of people who do this with P25 gear. But I don't
see any useful cases in which HamWAN could make use of encryption
while publishing the keys.<div class="im"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>The frequencies that we're allowed to use as
licensed radio amateurs belong to the public and we're allowed
to use them for the purposes of experimentation and
communication with other amateurs. In order to assure the
fair use of such a valuable resource, we have to follow strict
rules that prevent commercial interests from taking over.
That's why we're not allowed to conduct business on the air
or communicate with the general public (broadcast). That's
also why it's important that anything transmitted is not
intentionally obfuscated from anyone else's ability to view
it.</div>
<div><br>
</div>
</div>
</blockquote>
<br></div>
I see the <a href="http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr&SID=ad552c047464dd8e611924492c5b41c6&rgn=div5&view=text&node=47:5.0.1.1.6&idno=47#47:5.0.1.1.6.1.157.2" target="_blank">definition
of broadcast</a> you cite there, and boy is that a weird one. I'd
counter this with my phone patch example, and cite the <a href="http://www.arrl.org/phone-patch-guidelines" target="_blank">ARRL guidance</a>
on the matter, which allow communication with non-amateur third
parties (is that the same as "general public"?). In fact, the ARRL
guidance counters what has been said about commercial communications
in a previous thread:<br>
<br>
<small><font face="Courier New, Courier, monospace">Calls to place
an order for a commercial product may be made such as the
proverbial call to the pizza restaurant to order food, but not
calls to one's office to receive or to leave business messages
since communications on behalf of ones employer are not
permitted.<br>
</font></small><br>
The ARRL guidance on reverse autopatch (inbound TCP) actually runs
counter to my views on the subject. In part, it states:<br>
<br>
<small><font face="Courier New, Courier, monospace">Incoming calls
to an autopatch must be answered and screened off the air by the
control operator to ensure rule compliance. If an incoming call
automatically causes the repeater to transmit, even if it's just
a signal tone or notification message, then it is possible for
an unlicensed person to initiate a transmission without the
control operator's knowledge or approval, which is not
permitted.<br>
</font></small><br>
This to me sounds like we absolutely need a ham-controlled edge
firewall mechanism to "screen the calls off the air" as per the
individual hams' specifications.<br>
<br>
One thing is for sure: we're in brand new territory. We need to
tread with the utmost character so we set a good example for others
who follow us.<div class="im"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>As a long-time computer engineer with a
strong emphasis on security, the idea of having such an open
network is very scary to me. However, it's also why I'm
excited about the challenge. When most people think about
security, they only think about secrecy (hiding your
messages). However, security also includes authentication
(making sure messages really come from the intended sender)
and integrity (has this message been altered in transit).
With those two aspects and a lot of help from public key
cryptography, my hope is to contribute to making a network
that is both open *and* secure.</div>
<div><br>
</div>
<div>I've already made some strides in this area for
other ham-related projects of mine, and now I'm hoping to
translate that to the needs of the overall network.</div>
<div><br>
</div>
</div>
</blockquote>
<br></div>
This is exactly right. Well, almost. :) Cisco's thinking gets it
right when they refer to AAA: Authentication, Authorization and
Accounting. For anyone unfamiliar with what these concepts mean
exactly, can <a href="http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfaaa.html#wp1000889" target="_blank">refer
to this page</a>. Also Wikipedia has a <a href="http://en.wikipedia.org/wiki/AAA_protocol" target="_blank">page on AAA</a>.
The additional point you make about Integrity may not necessarily
fall under the "Authentication" concept, since that deals more with
actors in a network rather than the non-molestation of their
messages, but can be served nicely by an implementation of <a href="http://en.wikipedia.org/wiki/Ipsec#Authentication_Header" target="_blank">IPSec
in AH mode</a>.<br>
<br>
Tons of work here for sure, after the lower layers of the network
(RF) are up and running.<span class="HOEnZb"><font color="#888888"><br>
<br>
--Bart</font></span><div><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Feb 20, 2013 at 12:16 AM, Bart
Kus <span dir="ltr"><<a href="mailto:me@bartk.us" target="_blank">me@bartk.us</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>It's just a little more efficient to stop unwanted
traffic early, before it takes up a bunch of airtime.
Just an optimization, which may not be worth the
complexity right up front. Your suggestion works too.<span><font color="#888888"><br>
<br>
--Bart</font></span>
<div>
<div><br>
<br>
On 2/19/2013 8:46 PM, Benjamin Krueger wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">Just saw this, "just needs to push an
ACL update". Why can't we just route all traffic
and let the client nodes run their own firewalls?
We *really* don't want to be in the distributed
firewall business. :)</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Feb 13, 2013 at
4:04 PM, Bart Kus <span dir="ltr"><<a href="mailto:me@bartk.us" target="_blank">me@bartk.us</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Global reachability is not in conflict
with autonomy. Achieving both
simultaneously just requires careful
design of HamWAN network services. If the
HamWAN internet feed drops off, the
routing, DNS and other services need to
continue working. The first word in ASN
is Autonomous after all. :)<br>
<br>
I consider NAT and Proxies as old crusty
hacks from the age of ISPs giving out just
1 IP/customer. It's time to put these
ideas to rest. IPv6 will do this on the
commercial internet in the coming years,
and AMPRnet will allow us to do it
immediately here. For the cases where
communication is to be restricted due to
user preference, we can push filtering
rules to firewalls at the edges of the
network, and at the HamWAN <-> user
site interface. In short, firewalls: yes,
nat+gateways: no.<br>
<br>
If a user wants to make a service running
on one of his servers public, he just
needs to push an ACL update to HamWAN and
it'll be opened up. No need to re-IP,
update DNS, change NICs, whatever else.
And most importantly, it makes everyone
equal. Your subnet allocation has the
same powers as mine. There is no special
ground to fight over, such as space on a
public subnet, or access to some
officially sanctioned gateway servers that
are allowed to do special things.<br>
<br>
If you want though, you can of course live
in the world of private IPs and NAT. Just
configure your LAN router that way.<br>
<br>
Complete freedom of configuration. This
is the way the internet should have
evolved for geeks!<span><font color="#888888"><br>
<br>
--Bart</font></span>
<div>
<div><br>
<br>
<br>
On 2/13/2013 8:30 AM, Cory (NQ1E)
wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">Unless I've
misunderstood the point of this
network all together, there
shouldn't be a case where we want
the entire network address space to
be reachable from the global
internet. It's much more likely
that the network will remain as
autonomous as possible and any
connections to the internet will be
for connecting specific services
through a gateway of some sort.
<div> <br>
</div>
<div>A subnet of at least /23
(typical minimum for global BGP
announcements) should be reserved
for the purpose of being
globally routable in the future,
if/when HamWAN decides to peer
with one or more ISPs. An address
in the /23 can be given to each
service gateway for connecting to
the internet.</div>
<div><br>
</div>
<div>The rest of the 44-net
allocation can be treated as
private address space, except that
it's essentially guaranteed not to
cause conflicts with the
user-level networks since it's
still globally unique.</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Feb
13, 2013 at 2:28 AM, Bart Kus <span dir="ltr"><<a href="mailto:me@bartk.us" target="_blank">me@bartk.us</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Clever ;)<br>
<br>
What if HamWAN switches
ISPs? All that IPv6 space
would need to be given up.
It can't follow you AFAIK.
Or the ISP may charge
whatever they feel like to
let you take it with you.
Also bad.<br>
<br>
The fees for IPv6 are not as
low as I had hoped, but not
as high as you think
either! There's a 25%
discount in effect for
"extra-small" allocations
(which are still larger than
the entire IPv4 internet).
The cost looks to be
$937.50/yr. Not sure it's
worth the cost, given the
IPv4 AMPRnet situation. We
can very likely just expand
our AMPRnet allocation if we
out-grow the /20.<span><font color="#888888"><br>
<br>
--Bart</font></span>
<div>
<div><br>
<br>
<br>
On 2/13/2013 1:10 AM,
Cory (NQ1E) wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">Here's an
IPv6 allocation for
you ;)
<div><br>
</div>
<div>::ffff:<a href="http://44.24.240.0/116" target="_blank">44.24.240.0/116</a></div>
<div><br>
</div>
<div>With the obvious
exception of AMPRNet
addresses for
amateur radio use,
IP allocations
should come from an
ISP. Obtaining a
direct allocation
from ARIN would cost
around a couple
grand per year.</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On
Wed, Feb 13, 2013 at
12:46 AM, Bart Kus <span dir="ltr"><<a href="mailto:me@bartk.us" target="_blank">me@bartk.us</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Result: APPROVED<br>
Your allocated
subnet is: <a href="tel:44.24.240.0%20%2F%2020" value="+14424240020" target="_blank">44.24.240.0
/ 20</a><br>
<br>
<a href="https://portal.ampr.org/networks.php?a=region&id=191" target="_blank">https://portal.ampr.org/networks.php?a=region&id=191</a><br>
<br>
HamWAN now has
4096 real Internet
IPs to play with.
Next up: we gotta
crack the mystery
of getting IPv6
net space. Any
volunteers? :)<br>
<br>
What an incredibly
productive day,<br>
<br>
--Bart<br>
<br>
<br>
_______________________________________________<br>
PSDR mailing list<br>
<a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
<a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
PSDR mailing list
<a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a>
<a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
PSDR mailing list<br>
<a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
<a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
PSDR mailing list
<a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a>
<a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
PSDR mailing list<br>
<a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
<a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">Benjamin<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
PSDR mailing list
<a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a>
<a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
PSDR mailing list<br>
<a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
<a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
PSDR mailing list
<a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a>
<a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
PSDR mailing list<br>
<a href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a><br>
<a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
<br></blockquote></div><br></div>