[HamWAN PSDR] hamwan.net DDNS [was: hostname on ampr.org?]

[Bart Kus]

On 3/30/2014 1:56 AM, Dean Gibson AE7Q wrote:
>
> On 2014-03-21 23:09, Tom Hayward wrote:
>> On Fri, Mar 21, 2014 at 8:40 PM, Dean Gibson AE7Q<hamwan at ae7q.net>  wrote:
>>> ...
>> 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.
>
> 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": update-policy {  };
>
> Then, once for each user, you just need to do (substitute the user's 
> callsign for /*ae7q*/):
>
>  1. On a Linux system, run: dnssec-keygen -a HMAC-MD5 -b 128 -n HOST
>     /*ae7q*/
>  2. Send the user a copy of the "K/*ae7q*/.+157.#####.key" file.  The
>     user will use the key value in the radio's "/tool dns-update ..."
>     command (or equivalently, the Linux "nsupdate" 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).
>  3. In your master "named.conf" file, add the following line, using
>     the key value from the above file: key "/*ae7q*/" {algorithm
>     hmac-md5; secret "/key value.../"; };
>  4. In your master "named.conf" file, in the zone statement for
>     "hamwan.net", insert the following into the "update-policy"
>     clause: grant "/*ae7q*/" subdomain "/*ae7q*/.hamwan.net";
>  5. Reload BIND (named).  On CentOS: service named reload
>
> This way, users will only be able to create/update DNS records of the 
> form "anything.<only-their-callsign>.hamwan.net".
>
> -- Dean
>
> 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 ...).
>
>

Hi Dean,

Thanks for outlining that approach.  I have a few questions:

 1. 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?
 2. Is the authentication Part97 compatible?
 3. 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?

I don't think we'll be able to use this approach for a few reasons:

 1. 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.
 2. Even though you can update one server by talking to DNS directly,
    how does that change get to all the others?
     1. 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.
     2. 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.
 3. 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.
 4. 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.
 5. 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.

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.

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!

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.

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.

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 Authentication 
<https://www.hamwan.org/t/tiki-index.php?page=Authentication&structure=HamWAN> 
page lists all the solutions we've brainstormed to date.  Feel free to 
address this problem space too.

--Bart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20140330/45de4077/attachment.html>