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

[Bart Kus]

On 3/30/2014 5:42 PM, Dean Gibson AE7Q wrote:
> Responses inline, bolded in blue:
>
> On 2014-03-30 12:38, Bart Kus wrote:
>> 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.*
>>

Thanks!  It does indeed look like TSIG is P97-compatible.  Good to know, 
we may use it as some point.

>> 1.
>>
>>
>> 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).*
>>

If you're referring to the use of TSIG as a signature at the end of a 
message, then yes, that hash is not encrypting any information, it's 
simply signing something as being legitimate.  But when you're talking 
about getting a private key from point A to point B over the network, 
and encrypting it during transmission so that it's not visible to 
others, then I believe that's violating FCC regulations. That's what I 
mean when I say we can't use PSKs: because their dissemination is not 
compatible with P97, even though their application is.

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

Yup, we're in a bad spot here.  Presently trying to figure out how to 
enable SSH with authentication and integrity, but not encryption.  There 
are other alternatives being considered such as IPsec(AH)+telnet, but 
they're far more gross than fixing SSH to be P97 compatible.  The 
problem is there exists no protocol in the world that provides remote 
control over ham radio in a secure way that respects P97.  Hams haven't 
yet done the work to invent one. We're trying.

>> 1.
>>
>>
>>  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).*
>>

It was a rhetorical question to setup the answers in the indented list 
below.  :)

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

No need to worry about changes here.  HamWAN authoritative DNS servers 
shall forever and always(*) be on 44.24.244.2 and 44.24.245.2.  These 
are anycast IPs from 2 different anycast ranges.  They're documented on 
the Core Routing 
<https://www.hamwan.org/t/tiki-index.php?page=Core+Routing&structure=HamWAN> 
page.  A similar pair (.1) are allocated to recursive DNS service.  
These should also be global and present in other people's HamWAN 
instances in other states.  A roaming client wouldn't need to change a 
thing when going from system to system. As we spin up Memphis and 
Michigan, we're helping those teams ensure seamless compatibility.

* = OK, we might at some point use different IPs for unforeseeable 
reasons.  Forever is a long time.  But as far as the present design of 
this, there's no need to change those IPs in the face of any presently 
possible network changes.

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

Distributed peer systems do not have this property.  It's time to shed 
those shackles and embrace a better tomorrow!  A change can be submitted 
via any node in the peer cloud.  There is no master or authority, other 
than the peer cloud itself.  The challenge in such systems is how do you 
resolve conflicts.  SymmetricDS provides a rich set of conflict 
resolution solutions.  Also note that this means not all nodes will 
always agree on what the data should be at all times, but they will 
eventually come to a consensus.  This is fine for DNS and many other 
systems, as it just introduces a delay while maintaining consistency in 
the long run.

>>      1. *BIND slaves do not become inoperative just because the
>>         master goes down.  For extended outages, it's pretty easy to
>>         swap masters.*
>>

Regarding swapping masters, the less human involvement in the face of 
failure, the better.  I automatically raise an eye when someone says "If 
X breaks, we'll login and do Y".  That's a fragile design - one that 
relies on a human timely response.  Right now we have "if a link breaks, 
OSPF will re-route the packets", which is a fine solution.  Need more of 
that.

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

I wasn't making a distinction.  It's just yet-another file to worry 
about keeping private.  Added hassle.  Bad.

>> 1.
>>
>>
>>  2. 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.
>>  3. 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.*
>>

Depends how you define "on the HamWAN network".  :)  We only keep track 
of modems, not the systems behind them.  I've got something like 15 
boxes here that are connected, not sure what others have.

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

The BIND choice isn't about scalability, it's about stability.  I can 
take you through some awesome BIND failures I've seen over the years.  
Let's do that not-in-this-email though.

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

As far as HMAC and identity hashes go, I agree.

>  1.   In other words, what is the *intent of any obscuration*?
>

I'd also say that the output of a hash function when used as a message 
or identity signature is not obscured in any way.  The signature is 
transmitted in plaintext over the air for anyone to inspect.  The 
signature is the message, and it obscures nothing.  In the case of HMAC, 
it signs the plaintext content preceding it right on the air.  Truly 
everything is out in the open.

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

Yup, and hams need to get off their collective butts and fix this. There 
is no protocol known to me which allows hams to have secure control 
without also engaging encryption of the content.

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

Yeah, but I aspire to provide the best solutions I can.  I've got no 
interest in releasing half-assed designs.  Anyone can do that and it 
doesn't advance anything.  Complexity does not equal failure or 
unusability.  It's all about wrapping all the complexity into a simple 
user experience in the end.  Cars are incredibly complicated things, but 
they boil down to a wheel and some pedals for the end user.  Right now 
HamWAN is at the stage of assembling engines in the factory.  There's a 
lot of engineering work to go around.  To help users cope with all the 
changes and exposed complexity happening right now, we're suggesting the 
shared administration model.  Since you chose not to participate in 
that, you need to keep up on your own.  I would also point out that you 
allow Comcast or whoever your ISP is to manage your modem, since they 
don't even give you a choice.  Could you imagine what Comcast would have 
to deal with if they had to call up every user to do something on their 
end every time they changed DOCSIS channels on the network?

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

What do you want/need right now?  If it's DNS entries, we can do that by 
hand.  If it's a static IP, I wanted to use your modem as a guinea pig 
for the BGP iteration of the design.  Yes, I'm placing design 
verification needs above your user satisfaction when I do that.  :)  
I've been working with WE7X on a non-BGP static IP setup, but he's got 
an atypical situation going on there since he's a relay site.  Not a 
good test case for the typical static IP scenario.

> 1.
>
>
>  2. 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".
>

Sounds like a reasonable description of the situation.  No longer sure 
how it fit into the larger picture of the email.  :)

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

Yup, as stated above, user experience being simple is important. You're 
experiencing an unfinished network with all the complexity out in the 
open.  You've also made it harder on yourself by disallowing remote 
access for network operator folks.  That's a personal choice you're of 
course free to make with your hardware, but I think it's safe to say 
we're not gonna stop pushing for our goals to keep the complexity you're 
chosen to take on low.

>  1.   Continuity (eg, among project member changes) also suggests
>     simplicity.
>

Also, good documentation.  We're documenting things as they get 
finalized and publishing everything.  Anyone not familiar with the 
project but familiar with computers/networking, should be able to surf 
that wiki and solve any problem.

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

BGP isn't solely about roaming.  It's also about security.  The protocol 
stack I need to verify is to ensure noone else clones your MAC and 
steals your IP address and your traffic.  The simple solution in this 
case (static DHCP) is really vulnerable and not suitable for wide 
deployment.  See the Point to Multipoint Authentication 
<https://www.hamwan.org/t/tiki-index.php?page=Point+to+Multipoint+Authentication&structure=HamWAN> 
page for a (slightly outdated) authentication sequence and main 
communication mode between cell sites and clients.

If this weren't part 97, things would be really simple.  We'd throw WPA2 
up on the APs and everyone would get a login.  Sadly that encrypts 
things, so we can't use these industry standards on ham radio.  We're 
forced to go to great lengths to remain both secure and compliant.  
You're experiencing the outcome of collective ham laziness not having 
yet invented the digital future.

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

I can confirm that when you roam, you'll indeed be able to pull DHCP.  
Another option you'll have when you roam is that after you've pulled 
DHCP, you can also engage BGP to announce a subset of your allocation.  
For example, if your home has a /29 allocated, you can announce just a 
/32 from that to your roaming client.  The network will re-route that 
/32 away from your home and to your roaming client.  Flexible!

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

What are we blocking in your tinkering?  The two examples you mentioned 
(DNS and static IP) we can address right now.  DNS we can do by hand, 
and static IP is fairly static for you even with just DHCP.  I could do 
a temporary static DHCP assignment there but be aware of the hijacking 
issue I mentioned.  The temporary period will expire when the Point to 
Multipoint Authentication protocol stack is verified and deployed.

What kind of tinkering are you thinking of doing?  Perhaps some of that 
information might drive some inputs to our design plans.  I'd like to 
know how people use the network in general.

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

Me too!  I think hams are really into the theory of being on a microwave 
digital network, but not so motivated to go out and buy the hardware, 
configure it, install it, align it, and integrate it into their home 
network.  I know of at least 2 examples where folks have actually bought 
the hardware and have been in a coverage zone for months, but just 
haven't deployed it.  This may very well be a ham culture issue.  Ham 
radio has been very focused on analog voice systems.  Learning how to do 
digital network comms does take time and effort.  Time changes all 
things though, and I'm encouraged by the new hams we've minted through 
this project.  I'd like for us to focus on ham-recruitment of 
digital-savvy folks in the future.  They may have an easier time of 
adopting HamWAN type technologies.  And of course, we eventually need to 
get down to an appliance solution. There's a whole bunch of UI work 
involved with that.  We need programmers!

>   How did your last two weekend presentations go?
>

As well as could be expected, I suppose.  I'm pretty sure I lost both 
audiences, except for 1-2 guys in each one who had previous network 
experience.  These deep-dive talks that focus on a specific subject are 
not appropriate for general audiences, so I'm calling my experiment a 
failure and will be using other methods going forward.

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

Yeah, the trial offer needs more promotion.  It's difficult to structure 
it though from an accounting and tax standpoint.  That's why it's not on 
the front page.  We need some financial people to bring this to a wider 
audience.  Or just some other entity we can link to that can handle the 
trial hardware program.  Perhaps some clubs can step up or something, I 
dunno.

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

BTW, I believe this is the longest email I've written in over a year.  
Gotta knock that off.  :)

--Bart

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