[HamWAN PSDR] Holy smokes, we have Internet address space!
Bart Kus
me at bartk.us
Wed Feb 20 21:55:51 PST 2013
First of all, +1, Informative.
On 2/20/2013 11:22 AM, Cory (NQ1E) wrote:
> 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.
>
> 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.
>
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.
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.
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.
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.
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!
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.
> 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).
>
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.
> 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.
>
I see the definition of broadcast
<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>
you cite there, and boy is that a weird one. I'd counter this with my
phone patch example, and cite the ARRL guidance
<http://www.arrl.org/phone-patch-guidelines> 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:
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.
The ARRL guidance on reverse autopatch (inbound TCP) actually runs
counter to my views on the subject. In part, it states:
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.
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.
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.
> 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.
>
> 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.
>
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 refer to this page
<http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfaaa.html#wp1000889>.
Also Wikipedia has a page on AAA
<http://en.wikipedia.org/wiki/AAA_protocol>. 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 IPSec in AH mode
<http://en.wikipedia.org/wiki/Ipsec#Authentication_Header>.
Tons of work here for sure, after the lower layers of the network (RF)
are up and running.
--Bart
>
>
>
>
> On Wed, Feb 20, 2013 at 12:16 AM, Bart Kus <me at bartk.us
> <mailto:me at bartk.us>> wrote:
>
> 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.
>
> --Bart
>
>
> On 2/19/2013 8:46 PM, Benjamin Krueger wrote:
>> 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. :)
>>
>>
>> On Wed, Feb 13, 2013 at 4:04 PM, Bart Kus <me at bartk.us
>> <mailto:me at bartk.us>> wrote:
>>
>> 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. :)
>>
>> 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.
>>
>> 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.
>>
>> If you want though, you can of course live in the world of
>> private IPs and NAT. Just configure your LAN router that way.
>>
>> Complete freedom of configuration. This is the way the
>> internet should have evolved for geeks!
>>
>> --Bart
>>
>>
>>
>> On 2/13/2013 8:30 AM, Cory (NQ1E) wrote:
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>
>>>
>>> On Wed, Feb 13, 2013 at 2:28 AM, Bart Kus <me at bartk.us
>>> <mailto:me at bartk.us>> wrote:
>>>
>>> Clever ;)
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> --Bart
>>>
>>>
>>>
>>> On 2/13/2013 1:10 AM, Cory (NQ1E) wrote:
>>>> Here's an IPv6 allocation for you ;)
>>>>
>>>> ::ffff:44.24.240.0/116 <http://44.24.240.0/116>
>>>>
>>>> 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.
>>>>
>>>>
>>>> On Wed, Feb 13, 2013 at 12:46 AM, Bart Kus <me at bartk.us
>>>> <mailto:me at bartk.us>> wrote:
>>>>
>>>> Result: APPROVED
>>>> Your allocated subnet is: 44.24.240.0 / 20
>>>> <tel:44.24.240.0%20%2F%2020>
>>>>
>>>> https://portal.ampr.org/networks.php?a=region&id=191
>>>>
>>>> HamWAN now has 4096 real Internet IPs to play with.
>>>> Next up: we gotta crack the mystery of getting
>>>> IPv6 net space. Any volunteers? :)
>>>>
>>>> What an incredibly productive day,
>>>>
>>>> --Bart
>>>>
>>>>
>>>> _______________________________________________
>>>> PSDR mailing list
>>>> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
>>>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> PSDR mailing list
>>>> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
>>>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>>
>>>
>>> _______________________________________________
>>> PSDR mailing list
>>> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
>>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> PSDR mailing list
>>> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
>>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>
>>
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>
>>
>>
>>
>> --
>> Benjamin
>>
>>
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>
>
>
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20130220/a1e3de65/attachment.html>
More information about the PSDR
mailing list