<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Responses inline, bolded in blue:<br>
<br>
<div class="moz-cite-prefix">On 2014-03-30 12:38, Bart Kus wrote:<br>
</div>
<blockquote cite="mid:53387299.4090206@bartk.us" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 3/30/2014 1:56 AM, Dean Gibson
AE7Q wrote:<br>
</div>
<blockquote cite="mid:5337DC41.9050209@ae7q.net" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 2014-03-21 23:09, Tom Hayward
wrote:<br>
</div>
<blockquote
cite="mid:CAFXO5Z3XtqV_2_yNMvnR1xw0AbD0VSnG0KQOxTMvn-=gGmtvEQ@mail.gmail.com"
type="cite">
<pre wrap="">On Fri, Mar 21, 2014 at 8:40 PM, Dean Gibson AE7Q <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:hamwan@ae7q.net"><hamwan@ae7q.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">...
</pre>
</blockquote>
<pre wrap="">Dean,
This is a really good question. DNS is an essential service for a network. It makes higher-level services much more useful (who wants to memorize IP addresses? Okay... other than me!). HamWAN plans to let you create *.hamwan.net hostnames. At the moment, the DNS servers are running (redundant, at multiple sites), but there's no user interface for people like you to add entries. Only a few records have been manually entered.
</pre>
</blockquote>
<br>
You have a user interface. If you are running ISC's BIND
version 9, in your master "named.conf" file, add the following
clause to the "zone" statement for "hamwan.net": <font
color="#cc0000"><tt>update-policy </tt><tt>{ };</tt><br>
</font><br>
Then, once for each user, you just need to do (substitute the
user's callsign for <font color="#cc0000"><i><b>ae7q</b></i></font>):<br>
<ol>
<li>On a Linux system, run: <font color="#cc0000"><tt>dnssec-keygen
-a HMAC-MD5 -b 128 -n HOST </tt><i><tt><b>ae7q</b></tt></i></font></li>
<li>Send the user a copy of the "K<i><b>ae7q</b></i>.+157.#####.key"
file. The user will use the key value in the radio's <tt>"/tool
dns-update ..."</tt> command (or equivalently, the Linux <tt>"nsupdate"</tt>
command) whenever the IP address needs to be updated.
You'll need to tell the user the IP address of the master
DNS server (probably a.ns.hamwan.net = 44.24.244.2, unless
your A and B DNS servers are slaves to a hidden master).<br>
</li>
<li>In your master "named.conf" file, add the following line,
using the key value from the above file: <font
color="#cc0000"><tt>key "<i><b>ae7q</b></i>" {algorithm
hmac-md5; secret "<i>key value...</i>"; };</tt></font></li>
<li>In your master "named.conf" file, in the zone statement
for "hamwan.net", insert the following into the <tt>"update-policy"</tt>
clause: <font color="#cc0000"><tt>grant "</tt><i><tt><b>ae7q</b></tt></i><tt>"
subdomain "</tt><i><tt><b>ae7q</b></tt></i><tt>.hamwan.net"</tt><tt>;</tt></font></li>
<li>Reload BIND (named). On CentOS: <font color="#cc0000"><tt>service
named reload</tt></font><br>
</li>
</ol>
<p>This way, users will only be able to create/update DNS
records of the form
"anything.<only-their-callsign>.hamwan.net".<br>
</p>
<p>-- Dean<br>
</p>
<p>ps: I've tested this on my own DNS servers. It's much better
than using the zone "allow-update" clause, because the latter
applies to a whole zone (which would mean creating a new zone
for each user ...).<br>
</p>
</blockquote>
<br>
Hi Dean,<br>
<br>
Thanks for outlining that approach. I have a few questions:<br>
<ol>
<li>Where is the protocol for zone updating documented? I see
RFC 2136, but I don't see where it uses authentication
anywhere. How does the authentication work here? <font
color="#3333ff"><b>DDNS uses "TSIG":
<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/TSIG">http://en.wikipedia.org/wiki/TSIG</a></b></font><br>
</li>
<li>Is the authentication Part97 compatible? <font
color="#3333ff"><b>Not sure (see below); it's a signature
process using hashing.</b></font><br>
</li>
<li>Once an update session is authenticated, are there any
further provisions for integrity checking during the (I
assume) TCP? Are there HMACs sent along with it, or one giant
signature at the bottom? <font color="#3333ff"><b>I'm sure
the details are in the above link and its references.</b></font><br>
</li>
</ol>
I don't think we'll be able to use this approach for a few
reasons:<br>
<ol>
<li>It seems to rely on a shared secret. <font color="#3333ff"><b>Yes.</b></font>
We have a goal of being fully autonomous with no degradation
in network services when all other means of communication are
down. <b><font color="#3333ff">Yes, that's the whole point
of using multiple 44.x.x.x DNS servers.</font></b>
Passing shared secrets around securely under Part 97 is
impossible as far as I can tell. <font color="#3333ff"><b>I'm
not sure I agree (see below).</b></font> They need to be
"encoded for the purposes of obscuring their meaning" -- the
exact thing the FCC forbids, in order for them to remain
secrets. <font color="#3333ff"><b>There is no "meaning"
other than "authenticate me" (see below).</b></font>
Asymmetric cryptography is our only option, and only when it's
used as an integrity or identity mechanism. <font
color="#3333ff"><b>How does this apply to using SSH over the
air, which WamWAN enables by the distribution of SSH keys
on the Wiki? SSH not only authenticates, it encrypts
>>>all<<< the traffic. </b></font>Because
of all this, we actively avoid any pre-shared-key (PSK) or
password-based systems in our designs. <font color="#3333ff"><b>From
a legal perspective, I see that as a distinction without a
difference.</b></font><br>
</li>
<li>Even though you can update one server by talking to DNS
directly, how does that change get to all the others? <font
color="#3333ff"><b>That's a fundamental feature of BIND. </b><b>Historically,
the slaves query periodically (on the interval specified
in the SOA record). However, more recent (like the last
decade) versions of BIND have the master push updates to
the slaves. This is true when changes are made, whether
or not DDNS is used. The updates happen pretty quickly
(within a couple minutes).</b></font><br>
</li>
<ol>
<li>People update every single server explicitly? <font
color="#3333ff"><b>No; see above.</b></font> That's a
PITA, and when servers are down, they'll miss updates. I
wouldn't expect people to keep a retry queue on their own.
When servers are decommissioned/brought up this would mean
pushing a list of servers to users constantly. <font
color="#3333ff"><b>Not with BIND. Somewhere in the
44.x.x.x world there needs to be a fixed IP (multiple)
source of DNS info, just like the (13? or so) DNS root
servers. I've replaced my "root servers" file once in
ten years. Hopefully, things are not going to be so
dynamic in HamWAN that hamwan.net DNS servers are going
to be constantly on the move.</b></font> More PITA.</li>
<li>You rightly mentioned we could do a master server, but
this introduces a single point of failure. <font
color="#3333ff"><b>There has to be one authoritative
source in any system. BIND slaves do not become
inoperative just because the master goes down. For
extended outages, it's pretty easy to swap masters.</b></font>
Another design goal of HamWAN is to be as fault-tolerant as
possible. A single special server contradicts that goal
when that site goes offline. <font color="#3333ff"><b>Again,
BIND does ...</b></font> Yes, you can anycast the
special server's IP, but then you'd have an impossible
(read: unsupported) zone-update topology between the DNS
servers.</li>
</ol>
<li>This introduces yet-another piece of cryptographic identity
for people to keep secure. I'd like to avoid adding
complexity when it comes to identity. I'd like it all to boil
down to your private key for your PKI key pair. <font
color="#3333ff"><b>I don't understand the distinction. </b><b>A
private key isn't conceptually different from other
authentication schemes. You have secret files. I do
agree it would be nice to only have one key.</b></font><br>
</li>
<li>DNS is not the only piece of configuration people will need
to send to HamWAN when they want changes. Edge firewall rules
are another good example. I'm sure tons of others will
follow. For simplicity's sake, I'd like to unify it all under
a single configuration management system.</li>
<li>We don't use BIND. I've run it professionally and at scale
for enough years to have learned to avoid it. <font
color="#3333ff"><b>Well, I have more networked devices (64
distinct IP addresses as of this morning; all but six
currently online) in my house than are presently on the
HamWan network. They are all using DHCP (two servers
using failover) for the assignment of both static and
dynamic IP addresses. The two DHCP servers update five
internal DNS (BIND) servers. I don't think </b></font><font
color="#3333ff"><b><font color="#3333ff"><b>HamWAN </b></font>
will have to worry about scalability in my remaining
lifetime.</b></font> We use PowerDNS for our
authoritative DNS service, and Unbound for our recursive DNS
service. Even though PowerDNS will likely have equivalent
utilities/configuration options as you mentioned for BIND
above, the other problems remain.</li>
</ol>
<p>So, what ARE we doing here? We've chosen to keep the data
which feeds PowerDNS in a PostgreSQL database. This shifts the
problem of updates and replication into the database realm. The
presence of said database also provides us a fairly universal
and highly adaptable place to keep all other configuration and
state information. The problem is now reduced to just allowing
users secure and Part97 compatible access to PostgreSQL. That
problem is solved by PostgreSQL's support for certificate-based
authentication of users. We have not yet verified if the
sessions PostgreSQL provides also provide HMAC support after the
identity is established, while avoiding encryption. If that's
possible, then great, we're done. If not, we can do some
further work to make that happen.<br>
</p>
This still leaves the problem of how to avoid a single-master
single point of failure scenario. Luckily, we've figured out how
to turn PostgreSQL into a true multi-master (that means
write-anywhere) database by the use of a piece of software called
SymmetricDS. <font color="#3333ff"><b>[Idle comment: I use
PostgreSQL 9.0 replication among four PostgreSQL servers,
using "hot standby".]</b></font> There's nothing particularly
magical about this software, I'm sure we could implement an
equivalent in-house, but why bother when someone else has already
done it! East PostgreSQL server listens on a pair of anycast IPs,
which are pointed to by a single DNS record. No user
configuration or re-routing required when database servers or
network links go down!<br>
<br>
So at the end of the day, we've got a fully redundant multi-master
database, that is modifiable by users using Part97 compatible
protocols, using their single identity to keep things simple,
available via a single DNS name and pair of anycast IPs, which
happens to have authoritative DNS as one of the configuration
items it stores. This is absolutely foundational to our future
success in other services.<br>
<br>
Now for the big fat disclaimer. I've been extremely busy lately,
and the reality of what's actually up and running is: a single
instance of PowerDNS, a single instance of PostgreSQL, and no
instances of SymmetricDS. We haven't verified the user access
protocol. Right now we're at the stage of flipping some triggers
into stored procedures, since a design mistake was made with the
schema. We may or may not write some middleware to sit in front
of the database and terminate the user sessions, I just don't know
yet.<br>
<br>
While custom software that's Part97 compatible is do-able, and we
can release multi-platform solutions for simple command-line
configuration management, the web aspect of things is harder.
There is an open problem around how do we use existing web
browsers in such a way that's Part97 compatible and yet
authenticated and integrity enforced. HTTPS with null cipher used
to be an option, but all the browsers decided to "improve" their
software and removed null cipher support. The one thing on the
horizon that looks promising is WebCryptoAPI, which could allow
for JavaScript to HMAC all requests using the installed private
keys, without having direct access to the private keys. The <a
moz-do-not-send="true"
href="https://www.hamwan.org/t/tiki-index.php?page=Authentication&structure=HamWAN">Authentication</a>
page lists all the solutions we've brainstormed to date. Feel
free to address this problem space too.<br>
<br>
--Bart<br>
</blockquote>
<br>
<font color="#3333ff"><b>In conclusion ...,</b></font> the issues
here in my mind:<br>
<br>
<ol>
<li>Encryption: FCC Part 97.113 prohibits <i>"... </i><span><i>messages
encoded for the purpose of obscuring their meaning, except
as otherwise provided herein ..."</i>. The exceptions have
to do with <b>communication control</b> (model aircraft and
spacecraft) and not message content. I would think the FCC
would accept encryption as part of authentication (that's part
of securely <b>controlling the communication</b>), but not
message content. In other words, what is the <b>intent of
any obscuration</b>? For example, SSH (commonly port 22)
and HTTPS (commonly port 443) would be out, as would the
equivalent secure eMail protocols (ports 993, 995, 465,
etc...), as clear meanings in the <b>content</b> are
obscured. There is no "meaning" in a secure signature key
(other than "keep out"); the endpoints of the connection are
visible. It's the remaining/attached content that matters.<br>
</span></li>
<li><span>Redundancy: I appreciate that goal. However, true
redundancy requires either simplicity, or a long industry
history that proves the complexity to be reliable. If nothing
else, <b>the computer world is littered with complex
solutions </b><b>that don't work (or work well).</b> I see
the HamWAN design heading down that road. Meanwhile, we have
some simple "wants" (not "needs") that aren't being addressed,
due to a future "perfect" solution. I would much rather adopt
a scheme that works, and then improve it later as needed.<br>
</span></li>
<li><span>How often are the DNS updates: Hopefully most people
will (other than when setting up) will have low-frequency DNS
updates, at least of nodes that they consider "critical".<br>
</span></li>
<li><span>People's time: I'd guess that most of the people on
this list have a full-time job. I'm probably the exception,
being retired. Nevertheless, I have only so much time to give
to <b>any</b> project as well. For that reason, I think
simplicity is important. Continuity (eg, among project member
changes) also suggests simplicity. Just one example:</span></li>
</ol>
<p><br>
I asked about a hostname automatically tied to my IP address. I
don't <b>need</b> a fixed IP address. It would just be nice (not
to mention simple) for some things (like running a DNS server!).
And it doesn't even have to happen in the next two months (or
more). But when I asked, the response was to offer to set me up
with BGP, so that I can roam. A complex solution (?) proposed by
someone who has very little time (and I don't want to take any
more of that time than is necessary).<br>
</p>
<p>For the radio I have, <b>I don't want to roam; it took too much
effort to aim and mount the antenna !!!</b> (I presently have a
pulled muscle in my lower back from climbing around on the roof.)
If I want to roam, I will buy another radio and antenna (they're
inexpensive enough), and when I roam, I either expect to have a
varying DHCP address, <b>OR</b>, I will use my first radio to
keep track of the second radio's whereabouts, just like I do now
with my fixed IP-address DNS server in Boston keeping track of my
ISP's DHCP-assigned IP address here at home, and updating DNS as
needed.<br>
</p>
<p>Remember, I don't <b>n</b><b>eed</b> a fixed IP address or a
hostname tied to it, all within the 44.x.x.x network. It'd just
be nice. I have assigned "hamwan.ae7q.net" to my (first) radio,
since it appears that the assigned DHCP address doesn't change
across disconnects of more than a day. Yes, it won't be useful if
only the 44.x.x.x network is available, but what have I lost?<br>
</p>
<p>Here are my interests in the HamWAN network, in decreasing order
of "importance" (I have no plans to save the world in a
catastrophe):<br>
</p>
<ol>
<li>Network access to the Internet via HamWAN, that reasonably
survives a low-grade catastrophe. I presumably have that now
(but no guarantees).</li>
<li>Network access to the Snohomish County DEM site. That's more
guaranteed than #1 above, considering generators at both sites.</li>
<li>Network access to the full 44.x.x.x network. I have no idea
how meaningful this is. It's an area for tinkering.</li>
</ol>
<p>Remember, I bought the HamWAN radio/antenna (that was my reason
for coming to Puyallup this month), because of delays in the
Universal Digital Radio project. I wanted something that works
now, and Scott Honaker put me on to your project. I've now got
something that works now, and am grateful for the effort (past,
present, and future) that's gone into the HamWAN project by all
that have been involved. I would just like to tinker (the amateur
equivalent of "experiment") with some simple things without
waiting for the grand solution.<br>
</p>
<p>Now, what do others want? I have no idea. I would have thought
that, in the past year, you would have more than a dozen or so
participants. How did your last two weekend presentations go?
Granted that "location, location, location" is a big deal here, I
can understand some hesitancy, but hey, the investment to try it
out is minimal, especially with your "try it" offer. Of course,
we're all in a "fringe" area of interest in amateur radio ... too
many think their handheld is what it's all about. I'm reminded of
a huge multi-agency EmComm exercise a few years ago that I
participated in. I was assigned as a radio liaison to a fire
chief, and when he saw I had a nice camera, he told me to stow the
radio and take pictures ...<br>
<br>
</p>
</body>
</html>