Subject: [homenet] A TOFU approach to naming things in the homenet (with code!)

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 14 Apr 2017 02:38:46 +0200

Hey everyone

While following the naming discussions, I have been thinking about how
to do one of the things that the current naming architecture draft
excludes: Allowing devices on the homenet to register in (public) DNS so
that one may find them. And since I also wanted to learn the Go
programming language, I decided to prototype something. Enter the
'nsregd' daemon.

This daemon will allow a client to claim a name on a Trust On First Use
(TOFU) basis using the RFC2136 dynamic DNS update protocol. A client
claims a name by sending a DNS update request with a SIG(0) (RFC2931)
signature and including the public key corresponding to the signature.
If the name in a claim is not already taken by another client, the
client's claim will be successful and the daemon will cache the public
key and use it to verify subsequent update requests.

Once a name has been claimed by a client, that client can add and remove
A and AAAA records by means of regular DNS update requests signed with
the key used to claim the name. The daemon will forward these updates to
one or more configured upstream authoritative nameservers.

I'm posting this here in the hope that others will find it useful,
either as input to the discussion, or as a tool to play around with.

The code is available on Github:

https://github.com/tohojo/nsregd

The README file has a few more details on how it's supposed to work.
Comments very welcome, patches even more so :)

Cheers,

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Apr 2017 21:29:21 -0400

Thanks for doing this!   Did you come up with this on your own, or were inspired by https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-01 <https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-01> section 3.4.2 and https://tools.ietf.org/html/draft-lemon-stateful-dnssd-00 <https://tools.ietf.org/html/draft-lemon-stateful-dnssd-00> section 4.2?

I ask both because I'm curious of you're proposing that the previous naming architecture document is more in line with what you think should be on a homenet, and also because I'm curious whether you are interested in working on the documents.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 14 Apr 2017 15:34:01 +0200

Ted Lemon <[email-masked]> writes:

> Thanks for doing this! Did you come up with this on your own, or were
> inspired by
> https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-01
> section 3.4.2 and
> https://tools.ietf.org/html/draft-lemon-stateful-dnssd-00 section 4.2?

Well, I would by no means claim to have come up with the idea in a
vacuum. As I said, I have been following the naming discussions on this
list. I think I read the -00 of the naming architecture, but I have not
read the latest version, nor have I read the stateful-dnssd draft
before.

Looking at it now, what I have implemented looks like a hybrid of the
two halves of section 3.4.2. I.e., clients generate a KEY and use it to
sign updates, and they use that to remove records as well (i.e., there
is no support for unauthenticated updates in nsregd). But the records
are not permanent; the daemon will expire records that the client does
not maintain (since if a client drops off the network it has no way of
retiring its record).

> I ask both because I'm curious of you're proposing that the previous
> naming architecture document is more in line with what you think
> should be on a homenet, and also because I'm curious whether you are
> interested in working on the documents.

Hmm, well, I have first and foremost been trying to scratch my own itch
here. I was looking for something to replace dnsmasq's slaac address guessing
(https://tools.ietf.org/id/draft-taht-kelley-hunt-dhcpv4-to-slaac-naming-00.html),
and since no good solutions were forthcoming, I decided to roll my own.

That being said, I do believe this mechanism could be useful as part of
the homenet architecture, which is why I posted it here. And I wouldn't
mind spending some time fleshing out the mechanism and putting it into a
draft, if that is what you mean by "working on the documents"?

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 14 Apr 2017 15:51:42 +0200

Simple and elegant, solves a real problem without too much ideology.

> (TOFU) basis

Cool.

> If the name in a claim is not already taken by another nclient, the

Does this imply there's a single daemon in the Homenet?  How does the
network elect it in case there are multiple claimants?  How does the
client learn the address of the daemon?

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 14 Apr 2017 16:16:19 +0200

> Simple and elegant, solves a real problem without too much ideology.

Thank you! That is high praise, coming from you :)

> client learn the address of the daemon?

In the current implementation, a single daemon per registration zone.
The client will query for a SRV at _nsreg._tcp.<zone> to find the
daemon, which can be anywhere, in principle (the daemon will only speak
TCP and limits initial registration to a list of configured subnets; I'm
currently running mine on a separate server rather than on my router).
For the multi-homed homenet case, I suppose each uplink could have a
separate zone?

I punted somewhat on how to discover the zone; the client will currently
take it as a command line parameter. But figure that can be distributed
via DHCP/RA?

In principle, there's nothing preventing the daemon state from being
replicated across the homenet routers, I suppose...

-Toke

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 Apr 2017 10:37:09 -0400

I really like this idea.  Obviously, it's the sort of thing whose
scope had better be pretty limited (e.g. you better know what network
those TOFU requests are coming from), but apart from that it seems
quite useful.

A

On Fri, Apr 14, 2017 at 02:38:46AM +0200, Toke Høiland-Jørgensen wrote:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Andrew Sullivan
[email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 14 Apr 2017 17:05:44 +0200

> In the current implementation, a single daemon per registration zone.

Right.  Either it could be elected by HNCP, or the daemons could run an
election among themselves.

> currently running mine on a separate server rather than on my router).

Makes sense.  The list of prefixes could be configured by HNCP.

> For the multi-homed homenet case, I suppose each uplink could have a

Don't know.  I suppose so.

> take it as a command line parameter. But figure that can be distributed

Or put it in DNS under dot-home?  Since the client already knows how to
speak DNS, this avoids yet another coupling between protocols.

> replicated across the homenet routers, I suppose...

I think it's more complicated and more fragile than having an election.
I'm not too keen on adding another flooding protocol to the Homenet stack.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 14 Apr 2017 23:41:47 +0200

Andrew Sullivan <[email-masked]> writes:

> I really like this idea.

Thanks!

> Obviously, it's the sort of thing whose scope had better be pretty
> limited (e.g. you better know what network those TOFU requests are
> coming from), but apart from that it seems quite useful.

Yeah. The daemon will only allow new registrations from configured
white-listed subnets (and only speaks TCP to avoid spoofing problems).
Subsequent authenticated updates can optionally be allowed for any IP.

-Toke

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 14 Apr 2017 23:52:40 +0200

> election among themselves.

Yeah, this makes sense if this mechanism is also used inside the homenet
(to register under dot-home, say). For a globally visible zone (where
you'd presumably only install globally routable addresses) the daemon
could also be outside the homenet.

> Makes sense.  The list of prefixes could be configured by HNCP.

Yup.

> speak DNS, this avoids yet another coupling between protocols.

Ah yes, that makes sense; since we have a domain that always refers to
the homenet, just define a name under that that will return PTRs to the
zones available for registration.

> I think it's more complicated and more fragile than having an
> election. I'm not too keen on adding another flooding protocol to the
> Homenet stack.

I said it's possible in principle. I didn't say it was a good idea... ;)

-Toke

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 17 Apr 2017 21:16:28 +0200

> zones available for registration.

Hmm, turns out RFC6763 already defines a way to do this (in section 11).
r._dns-sd._udp.<domain>. where <domain> is either the in-addr.arpa zone
derived from the network address of a host address, or "local.". I guess
I'll teach the nsregc client to resolve that...

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Apr 2017 15:34:02 -0400

> I'll teach the nsregc client to resolve that...

Cool!   Sorry I didn't mention it earlier—haven't had a chance to try the code yet.   Thanks for GPLing it, BTW.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 24 Apr 2017 17:09:06 +0200

Ted Lemon <[email-masked]> writes:

> Cool!   Sorry I didn't mention it earlier—haven't had a chance to try
> the code yet. 

No worries. I added auto-discovery to the client, and improved
configuration for both client and server (and the client will now run
without any configuration with sensible defaults). The server also
supports synthesising reverse PTR records now.

Only thing missing now for my own use case is the ability to add local
records to Unbound (for having a separate internal view while keeping
private addresses out of the global DNS).

> Thanks for GPLing it, BTW.

You're welcome! The GPL is my default license :)

-Toke