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

[Dean Gibson AE7Q]

Responses inline, bolded in blue:

On 2014-03-30 12:38, Bart Kus wrote:
> 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? *DDNS uses "TSIG":
>     http://en.wikipedia.org/wiki/TSIG*
>  2. Is the authentication Part97 compatible? *Not sure (see below); 
>     it's a signature process using hashing.*
>  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'm sure the details are in the above link and its
>     references.*
>
> 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. *Yes.* We have a goal of
>     being fully autonomous with no degradation in network services
>     when all other means of communication are down. *Yes, that's the
>     whole point of using multiple 44.x.x.x DNS servers.* Passing
>     shared secrets around securely under Part 97 is impossible as far
>     as I can tell. *I'm not sure I agree (see below).*  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.
>     *There is no "meaning" other than "authenticate me" (see below).*
>     Asymmetric cryptography is our only option, and only when it's
>     used as an integrity or identity mechanism. *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. *Because of all this, we
>     actively avoid any pre-shared-key (PSK) or password-based systems
>     in our designs. *From a legal perspective, I see that as a
>     distinction without a difference.*
>  2. Even though you can update one server by talking to DNS directly,
>     how does that change get to all the others? *That's a fundamental
>     feature of BIND. **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).*
>      1. People update every single server explicitly? *No; see
>         above.*  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. *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.*  More PITA.
>      2. You rightly mentioned we could do a master server, but this
>         introduces a single point of failure. *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.* 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. *Again, BIND does ...*  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. *I don't understand the
>     distinction. **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.*
>  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. *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 ***HamWAN * will have to worry about
>     scalability in my remaining lifetime.*  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. *[Idle 
> comment:  I use PostgreSQL 9.0 replication among four PostgreSQL 
> servers, using "hot standby".]*  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

*In conclusion ...,* the issues here in my mind:

 1. Encryption:  FCC Part 97.113 prohibits /"... //messages encoded for
    the purpose of obscuring their meaning, except as otherwise provided
    herein ..."/.  The exceptions have to do with *communication
    control* (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 *controlling the
    communication*), but not message content.  In other words, what is
    the *intent of any obscuration*?  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 *content* 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.
 2. 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, *the computer world
    is littered with complex solutions **that don't work (or work
    well).*  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.
 3. 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".
 4. 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 *any* project as
    well.  For that reason, I think simplicity is important.  Continuity
    (eg, among project member changes) also suggests simplicity.  Just
    one example:


I asked about a hostname automatically tied to my IP address.  I don't 
*need* 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).

For the radio I have, *I don't want to roam;  it took too much effort to 
aim and mount the antenna !!!* (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, *OR*, 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.

Remember, I don't *n**eed* 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?

Here are my interests in the HamWAN network, in decreasing order of 
"importance" (I have no plans to save the world in a catastrophe):

 1. Network access to the Internet via HamWAN, that reasonably survives
    a low-grade catastrophe.  I presumably have that now (but no
    guarantees).
 2. Network access to the Snohomish County DEM site.  That's more
    guaranteed than #1 above, considering generators at both sites.
 3. Network access to the full 44.x.x.x network.  I have no idea how
    meaningful this is.  It's an area for tinkering.

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.

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 ...

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