<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">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=ISO-8859-1"
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>
<br>
</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?</li>
<li>Is the authentication Part97 compatible?</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?<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. We have a goal of being
fully autonomous with no degradation in network services when
all other means of communication are down. Passing shared
secrets around securely under Part 97 is impossible as far as I
can tell. 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. Asymmetric cryptography is
our only option, and only when it's used as an integrity or
identity mechanism. Because of all this, we actively avoid any
pre-shared-key (PSK) or password-based systems in our designs.</li>
<li>Even though you can update one server by talking to DNS
directly, how does that change get to all the others?</li>
<ol>
<li>People update every single server explicitly? 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. More PITA.</li>
<li>You rightly mentioned we could do a master server, but this
introduces a single point of failure. 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. 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.</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. 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.
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
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>
<br>
</body>
</html>