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

[Benjamin Krueger]

Folks, please be civil. Please remember that if somebody doesn't understand
what you're trying to convey, it's generally your job to communicate more
clearly.


On Thu, Feb 21, 2013 at 11:42 PM, Cory (NQ1E) <cory at nq1e.hm> wrote:

> Well Daniel, I'm sorry if we're getting too technical for you.  However,
> that's what this list is for.
>
>
> On Thu, Feb 21, 2013 at 10:52 PM, <KL7WM at aol.com> wrote:
>
>> **
>> 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=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
>>>>>>>
>>>>>>> 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
>>
>>
>> _______________________________________________
>> 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/20130222/dcb6a2b8/attachment.html>