[HamWAN PSDR] Holy smokes, we have Internet address space!

Wed Feb 20 11:22:21 PST 2013

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.

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).

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.

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.

On Wed, Feb 20, 2013 at 12:16 AM, Bart Kus <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> 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> 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
>>>
>>>  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> wrote:
>>>
>>>> Result: APPROVED
>>>> Your allocated subnet is: 44.24.240.0 / 20 <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
>>>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> PSDR mailing listPSDR at hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>>
>>>
>>>
>>> _______________________________________________
>>> PSDR mailing list
>>> PSDR at hamwan.org
>>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>>
>>>
>>
>>
>> _______________________________________________
>> PSDR mailing listPSDR at hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>
>>
>>
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org
>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>
>>
>
>
>  --
> Benjamin
>
>
> _______________________________________________
> PSDR mailing listPSDR at hamwan.orghttp://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/ffa304d5/attachment.html>