<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">First of all, +1, Informative.<br>
      <br>
      On 2/20/2013 11:22 AM, Cory (NQ1E) wrote:<br>
    </div>
    <blockquote
cite="mid:CAGOhXw+wPnHJLZ9B5GpaffCx6RNxuBQHJch1jUeKrcFgDrYSow@mail.gmail.com"
      type="cite">
      <div dir="ltr">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.
        <div>
          <br>
        </div>
        <div style="">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.</div>
        <div style=""><br>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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!<br>
    <br>
    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.<br>
    <br>
    <blockquote
cite="mid:CAGOhXw+wPnHJLZ9B5GpaffCx6RNxuBQHJch1jUeKrcFgDrYSow@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div style="">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).</div>
        <div style=""><br>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote
cite="mid:CAGOhXw+wPnHJLZ9B5GpaffCx6RNxuBQHJch1jUeKrcFgDrYSow@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div style="">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.</div>
        <div style=""><br>
        </div>
      </div>
    </blockquote>
    <br>
    I see the <a
href="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">definition
      of broadcast</a> you cite there, and boy is that a weird one.  I'd
    counter this with my phone patch example, and cite the <a
      href="http://www.arrl.org/phone-patch-guidelines">ARRL guidance</a>
    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:<br>
    <br>
    <small><font face="Courier New, Courier, monospace">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.<br>
      </font></small><br>
    The ARRL guidance on reverse autopatch (inbound TCP) actually runs
    counter to my views on the subject.  In part, it states:<br>
    <br>
    <small><font face="Courier New, Courier, monospace">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.<br>
      </font></small><br>
    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.<br>
    <br>
    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.<br>
    <br>
    <blockquote
cite="mid:CAGOhXw+wPnHJLZ9B5GpaffCx6RNxuBQHJch1jUeKrcFgDrYSow@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div style="">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.</div>
        <div style=""><br>
        </div>
        <div style="">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.</div>
        <div style=""><br>
        </div>
      </div>
    </blockquote>
    <br>
    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 <a
href="http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfaaa.html#wp1000889">refer
      to this page</a>.  Also Wikipedia has a <a
      href="http://en.wikipedia.org/wiki/AAA_protocol">page on AAA</a>. 
    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 <a
      href="http://en.wikipedia.org/wiki/Ipsec#Authentication_Header">IPSec
      in AH mode</a>.<br>
    <br>
    Tons of work here for sure, after the lower layers of the network
    (RF) are up and running.<br>
    <br>
    --Bart<br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:CAGOhXw+wPnHJLZ9B5GpaffCx6RNxuBQHJch1jUeKrcFgDrYSow@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div style=""><br>
        </div>
        <div style=""><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Wed, Feb 20, 2013 at 12:16 AM, Bart
          Kus <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:me@bartk.us" target="_blank">me@bartk.us</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text="#000000" bgcolor="#FFFFFF">
              <div>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.<span
                  class="HOEnZb"><font color="#888888"><br>
                    <br>
                    --Bart</font></span>
                <div>
                  <div class="h5"><br>
                    <br>
                    On 2/19/2013 8:46 PM, Benjamin Krueger wrote:<br>
                  </div>
                </div>
              </div>
              <div>
                <div class="h5">
                  <blockquote type="cite">
                    <div dir="ltr">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. :)</div>
                    <div class="gmail_extra"><br>
                      <br>
                      <div class="gmail_quote">On Wed, Feb 13, 2013 at
                        4:04 PM, Bart Kus <span dir="ltr"><<a
                            moz-do-not-send="true"
                            href="mailto:me@bartk.us" target="_blank">me@bartk.us</a>></span>
                        wrote:<br>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex">
                          <div text="#000000" bgcolor="#FFFFFF">
                            <div>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. :)<br>
                              <br>
                              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.<br>
                              <br>
                              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.<br>
                              <br>
                              If you want though, you can of course live
                              in the world of private IPs and NAT.  Just
                              configure your LAN router that way.<br>
                              <br>
                              Complete freedom of configuration.  This
                              is the way the internet should have
                              evolved for geeks!<span><font
                                  color="#888888"><br>
                                  <br>
                                  --Bart</font></span>
                              <div>
                                <div><br>
                                  <br>
                                  <br>
                                  On 2/13/2013 8:30 AM, Cory (NQ1E)
                                  wrote:<br>
                                </div>
                              </div>
                            </div>
                            <div>
                              <div>
                                <blockquote type="cite">
                                  <div dir="ltr">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.
                                    <div> <br>
                                    </div>
                                    <div>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.</div>
                                    <div><br>
                                    </div>
                                    <div>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.</div>
                                    <div><br>
                                    </div>
                                  </div>
                                  <div class="gmail_extra"><br>
                                    <br>
                                    <div class="gmail_quote">On Wed, Feb
                                      13, 2013 at 2:28 AM, Bart Kus <span
                                        dir="ltr"><<a
                                          moz-do-not-send="true"
                                          href="mailto:me@bartk.us"
                                          target="_blank">me@bartk.us</a>></span>
                                      wrote:<br>
                                      <blockquote class="gmail_quote"
                                        style="margin:0 0 0
                                        .8ex;border-left:1px #ccc
                                        solid;padding-left:1ex">
                                        <div text="#000000"
                                          bgcolor="#FFFFFF">
                                          <div>Clever ;)<br>
                                            <br>
                                            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.<br>
                                            <br>
                                            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.<span><font
                                                color="#888888"><br>
                                                <br>
                                                --Bart</font></span>
                                            <div>
                                              <div><br>
                                                <br>
                                                <br>
                                                On 2/13/2013 1:10 AM,
                                                Cory (NQ1E) wrote:<br>
                                              </div>
                                            </div>
                                          </div>
                                          <div>
                                            <div>
                                              <blockquote type="cite">
                                                <div dir="ltr">Here's an
                                                  IPv6 allocation for
                                                  you ;)
                                                  <div><br>
                                                  </div>
                                                  <div>::ffff:<a
                                                      moz-do-not-send="true"
href="http://44.24.240.0/116" target="_blank">44.24.240.0/116</a></div>
                                                  <div><br>
                                                  </div>
                                                  <div>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.</div>
                                                </div>
                                                <div class="gmail_extra"><br>
                                                  <br>
                                                  <div
                                                    class="gmail_quote">On
                                                    Wed, Feb 13, 2013 at
                                                    12:46 AM, Bart Kus <span
                                                      dir="ltr"><<a
                                                        moz-do-not-send="true"
href="mailto:me@bartk.us" target="_blank">me@bartk.us</a>></span>
                                                    wrote:<br>
                                                    <blockquote
                                                      class="gmail_quote"
                                                      style="margin:0 0
                                                      0
                                                      .8ex;border-left:1px
                                                      #ccc
                                                      solid;padding-left:1ex">
                                                      Result: APPROVED<br>
                                                      Your allocated
                                                      subnet is: <a
                                                        moz-do-not-send="true"
href="tel:44.24.240.0%20%2F%2020" value="+14424240020" target="_blank">44.24.240.0
                                                        / 20</a><br>
                                                      <br>
                                                      <a
                                                        moz-do-not-send="true"
href="https://portal.ampr.org/networks.php?a=region&id=191"
                                                        target="_blank">https://portal.ampr.org/networks.php?a=region&id=191</a><br>
                                                      <br>
                                                      HamWAN now has
                                                      4096 real Internet
                                                      IPs to play with.
                                                       Next up: we gotta
                                                      crack the mystery
                                                      of getting IPv6
                                                      net space.  Any
                                                      volunteers? :)<br>
                                                      <br>
                                                      What an incredibly
                                                      productive day,<br>
                                                      <br>
                                                      --Bart<br>
                                                      <br>
                                                      <br>
_______________________________________________<br>
                                                      PSDR mailing list<br>
                                                      <a
                                                        moz-do-not-send="true"
href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
                                                      <a
                                                        moz-do-not-send="true"
href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org"
                                                        target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
                                                    </blockquote>
                                                  </div>
                                                  <br>
                                                </div>
                                                <br>
                                                <fieldset></fieldset>
                                                <br>
                                                <pre>_______________________________________________
PSDR mailing list
<a moz-do-not-send="true" href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a>
<a moz-do-not-send="true" href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
                                              </blockquote>
                                              <br>
                                            </div>
                                          </div>
                                        </div>
                                        <br>
_______________________________________________<br>
                                        PSDR mailing list<br>
                                        <a moz-do-not-send="true"
                                          href="mailto:PSDR@hamwan.org"
                                          target="_blank">PSDR@hamwan.org</a><br>
                                        <a moz-do-not-send="true"
                                          href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org"
                                          target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
                                        <br>
                                      </blockquote>
                                    </div>
                                    <br>
                                  </div>
                                  <br>
                                  <fieldset></fieldset>
                                  <br>
                                  <pre>_______________________________________________
PSDR mailing list
<a moz-do-not-send="true" href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a>
<a moz-do-not-send="true" href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
                                </blockquote>
                                <br>
                              </div>
                            </div>
                          </div>
                          <br>
_______________________________________________<br>
                          PSDR mailing list<br>
                          <a moz-do-not-send="true"
                            href="mailto:PSDR@hamwan.org"
                            target="_blank">PSDR@hamwan.org</a><br>
                          <a moz-do-not-send="true"
                            href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org"
                            target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
                          <br>
                        </blockquote>
                      </div>
                      <br>
                      <br clear="all">
                      <div><br>
                      </div>
                      -- <br>
                      <div dir="ltr">Benjamin<br>
                      </div>
                    </div>
                    <br>
                    <fieldset></fieldset>
                    <br>
                    <pre>_______________________________________________
PSDR mailing list
<a moz-do-not-send="true" href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a>
<a moz-do-not-send="true" href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
                  </blockquote>
                  <br>
                </div>
              </div>
            </div>
            <br>
            _______________________________________________<br>
            PSDR mailing list<br>
            <a moz-do-not-send="true" href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a><br>
            <a moz-do-not-send="true"
              href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org"
              target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
PSDR mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a>
<a class="moz-txt-link-freetext" href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>