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

Thu Feb 21 23:32:44 PST 2013

And the next guy on the list will have just as convincing a reason as to why
you can't, and will cite some reference that nobody will check out and take
it as gospel.

I wonder why nobody wants to volunteer for anything anymore?  Probably
because we're such an effective bunch at communicating with each other.

Just shoot me now.

From: PSDR [mailto:psdr-bounces at hamwan.org] On Behalf Of KL7WM at aol.com
Sent: Thursday, February 21, 2013 10:53 PM
To: psdr at hamwan.org
Subject: Re: [HamWAN PSDR] Holy smokes, we have Internet address space!

I don't understand why you don't get it.  It is LEGAL TO ORDER PIZZA ON HAM
RADIO unless you own or work for the pizza business.  PERIOD.  

If you  are a pizza delivery driver you can't use amateur radio to get
direction to a customer.

We have swap net on amateur radio.  We talk about money on the air.  This is
OK TOO!

Daniel Stevens, KL7WM

In a message dated 2/20/2013 11:38:40 P.M. Pacific Standard Time,
cory at nq1e.hm writes:

It appears that we're getting our layers mixed up. 

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.

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.

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.

Using IPSec(AH) is a very good idea.

I have high hopes that this will all work out.  It sounds like so much fun,
I can't contain myself! ;)

-Cory

On Wed, Feb 20, 2013 at 9:55 PM, Bart Kus <me at bartk.us> wrote:

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=ad552c047464dd8e611924492c5
b41c6&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/scfaa
a.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> 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 <tel:44.24.240.0%20%2F%2020> 

https://portal.ampr.org/networks.php?a=region
<https://portal.ampr.org/networks.php?a=region&id=191> &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 list
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

_______________________________________________
PSDR mailing list
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

-- 

Benjamin

_______________________________________________
PSDR mailing list
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

_______________________________________________
PSDR mailing list
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

_______________________________________________
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/20130221/5ae58b5c/attachment.html>