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

[Benjamin Krueger]

We really need to think long and hard about whether it's a good idea to
connect this network to the internet. I am still unconvinced of the value
of this proposition, and it causes a great many extremely difficult
technical and legal challenges.

If nothing else, it is a distraction for us today. If we really want to
explore that feature of the network, we should do it in a future phase
after the network is already established. In the meantime, we can block
traditionally encrypted ports on the network as standard practice; no need
for one-off changes from end-users.


On Wed, Feb 20, 2013 at 11:38 PM, Cory (NQ1E) <cory at nq1e.hm> wrote:

> 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=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> 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
>>>
>>>
>>
>>
>> _______________________________________________
>> 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 list
> PSDR at hamwan.org
> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>
>


-- 
Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20130221/96fc3413/attachment.html>