Subject: [homenet] primary / secondary configuration

From: Daniel Migault <[email-masked]>
Date: Fri, 7 Jun 2019 16:27:53 -0400

Hi,

We are looking for a simple way to configure the primary / secondary DNS
setting between the homenet and the outsourcing infrastructure. The
exchange of these information is done over a secure channel - let say TLS.
While we coudl re-define a configuration template / mechanism we believe
that re-using widely deployed libraries would ease the deployment.

The HNA is responsible for building / signing the zone and synchronising
the zone with the outsourcing infrastructure. To build the zone some
elements of the infrastructure are needed such as the NS and IP for
example. One way to enable the transmission of information from the the
outsourcing infrastructure to the homenet is to use an well known fqdn
hna.example.com with an AXFR request. Does it sound reasonable ?

On the other hand, the outsourcing infrastructure needs to know the fqdn of
the hna. One way to provide that information could be to re-use DNS update
updating the SOA of hna.example.com. The fqdn of the hna would be indicated
using the MNAME field. Does it sounds reasonable as well ?

Yours,
Daniel

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Jun 2019 16:48:00 -0400

> hna.example.com with an AXFR request. Does it sound reasonable ?

So, during setup phase, the HNA does the equivalent of:

    % dig @configuration-server myDEVICE.r.example.net axfr

and gets back:
    myDEVICE.r.example.net IN SOA mname foo bar ...
                           IN NS ns1.example.com
                           IN NS ns2.example.com
                           IN NS ns3.example.com

which it uses as it's template for building it's zone, which is then signed
and AXFR'ed back to the distribution-master using the normal mechanisms.

There are probably some high-level details that we haven't gotten into the
document yet, which are important for understanding.

We drew this diagram in our call today:
  https://github.com/ietf-homenet-wg/ietf-homenet-hna/blob/master/hna-dm-cfg.svg

although I see some example.com->example.net, and foo.com->example.com edits that I
should make.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Sun, 9 Jun 2019 13:51:44 +0200

Daniel Migault wrote on 07/06/2019 22:27:
> Hi,
>
> We are looking for a simple way to configure the primary / secondary 
> DNS setting between the homenet and the outsourcing infrastructure. 
> The exchange of these information is done over a secure channel - let 
> say TLS. While we coudl re-define a configuration template / mechanism 
> we believe that re-using widely deployed libraries would ease the 
> deployment.
>
> The HNA is responsible for building / signing the zone and 
> synchronising the zone with the outsourcing infrastructure. To build 
> the zone some elements of the infrastructure are needed such as the NS 
> and IP for example. One way to enable the transmission of information 
> from the the outsourcing infrastructure to the homenet is to use an 
> well known fqdn hna.example.com <http://hna.example.com> with an AXFR 
> request. Does it sound reasonable ?
>

Stating the obvious: if an HNA is going to sign a zone, it has to own a 
globally unique delegated zone.

I see 3 ways of delegating a piece of namespace and gathering the input 
for the SOA:

1) HNA is pre-configured with one or more DNS outsourcing providers in 
the admin GUI e.g. <example.com>.

User picks one via LuCI.

HNA creates a proposed zone name e.g. <HN-ULA>.<example.com> or asks for 
a proposal from the user.

DNS Outsourcing Infra confirms that <HN-ULA>.<example.com> is unique via 
the parent zone <example.com>

2) HNA is pre-configured with one or more DNS outsourcing providers in 
the GUI e.g. <example.com>.

User picks one via LuCI.

HNA contacts <example.com>.

HNA receives the zone name  <HN-XXX>.<example.com> from the DNS 
Outsourcing Infra.

3) HNA owner purchases a nice name from a registrar e.g. 
<me.mydomain.com>. Domain Registrar and the DNS Outsourcing Infra 
example.com, don't share a common parent zone.

IMHO for (1) and (2) we already have working outbound DNS resolution in 
place, and the HNA can gather SOA variables using either a simple SOA 
lookup of the parent zone, or via a SOA + and AXFR to fetch a template.

(1) dig -t soa example.com +dnssec -> NS1 NS2 + AAAA RR + timers of the 
parent -> copied 1:1 to the child zone <hn-ULA>.example.com.
Obvious disadvantage: everyone is tied to the same infra, timers, and NS RR.
Advantage: cheap and cheerful.

(2) dig -t soa example.com +dnssec|perl extract_MNAME_from_SOA.pl; dig 
@$MNAME -t axfr <hn-ULA>.example.com +dnssec|perl extract_SOA_variables.pl;

The MNAME in example.com SOA would contain the name of the DM config 
server/template server.

The DM config server/template server would either have to generate the 
template on the fly, or have one pre-configured during sign up.

(3) would have to be out of band or require something much more complex.

> On the other hand, the outsourcing infrastructure needs to know the 
> fqdn of the hna. One way to provide that information could be to 
> re-use DNS update updating the SOA of hna.example.com 
> <http://hna.example..com>. The fqdn of the hna would be indicated 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Daniel Migault <[email-masked]>
Date: Tue, 18 Jun 2019 10:56:14 -0400

Hi Ray,

Thanks for the feed back, I have tried to look at how these various
configurations could work on a same device as well as how a new CPE can be
added and become HNA while HNA is being supported by other CPE. In my
example I am not using MNAME but a specific domain name, however I have no
strong preference over one way or the other. I am also not using TSIG not
SIG(0) but only rely on TLS.

I am happy to take any feed back from the WG and summarise the thought in
the next version of the draft.

I am also questioning on whether we should provide some sort of
recommendations for the UI. While we are not UI designers, I believe some
properties could be interesting for designers, and those may be helpful to
be provided.

Yours,
Daniel

  == UI (primary/secondary)

I am trying to figure out what the UI may look like.
OI = Outsourcing Infrastructure

Configuration Basic Parameters:

* Enable HNA (Bool):
defines if your CPE is willing to act as an HNA. The default should be
true.

When set to true, the following setting should be provided.

* Registered Homenet domain: (empty, or real one)
The homenet domain name, configuration is associated to one domain.
* Distributed Master (FQDN): (a default, your chosen OI).
Thought UI may find something more comprehensive for the end user.
** OI Identity (X509):
The identity associated to the OI.

Configuration Advanced Parameters:
* DNSSEC Keys: (file, or none)
The Cryptographic parameters for DNSSEC, KSK, ZSK

Button Action
* export DNSSEC key, identity
* set HNA

== Enabling HNA procedure (default procedure)

These are the foreseen steps to configure the HNA. The purpose of it is
to enable a CPE that is plug to become an HNA. In case of
incompatibility, WARNING or ERROR messages are returned. Some means
SHOULD be provided to the End User to go over the WARNING message,
especially if the End User knows what it is doing and agrees to move to
the Dangerous Zone.

All resolution are performed with DNSSEC.

* Step 1: Plug the CPE.
If HNA is enabled (default) with DNSSEC validating DM, move to Step 2

* Step 2: HNA Eligibility
This step check whether the CPE can potentially serve as an HNA and
consists in checking 1) the ability  to outsource the Public Homenet
Zone, 2) the ability to outsource the Public Homenet Zone, and 3) the
compatibility of acting as an HNA regarding the observed network
settings.

-- compatibility with existing network

The CPE checks if a Public Homenet Zone is already published, if so it
retrieves the necessary parameters to generate the Public Homenet Zone.

If no Registered Homenet Domain is provided. The CPE will not be able to
host the HNA function. An ERROR message is raised to the End user.

If the Registered Homenet Domain is provided, the CPE checks if the Public
Homenet Zone is already published via a SOA query.
    a) If NXDOMAIN is returned, the CPE may be a potential HNA. DS, KSK,
ZSK, NS are set to None.
    b) If a response is returned, the CPE retrieves associated DS, KSK,
ZSK, NS associated to the Public Homenet Zone.

Check compatibility between the DNSSEC retrieved parameters and those
provided in the CPE configuration.

If retrieved DNSSEC parameters are not set to None. The following tests
MUST be performed. 1) retrieved DS and retrieved KSK matches, 2) The HNA
hosts the private keys, 2) private keys and retrieved public keys
matches, 3) public keys and retrieved public keys also match. In case of
mismatch an ERROR is raised.
(Else)
    If the retrieved DNSSEC parameters are set to None. Check the parameters
provided in the CPE configuration, check correspondence between public,
private keys.

As a result, either DNSSEC parameters are set to None, or they are
coherent between themselves and to the network configuration.

--- ability to outsource the Pubic Homenet Zone

If DNSSEC parameters are set to None, generate a KSK, a ZSK.

If no identity is provided, use ACME to get a X509 certificate for the
KSK associated to the Registered Homenet Domain. We need to check a bit
deeper, but we could envision a web server is set to perform the ACME
procedure if needed.

DNSSEC validation of DM and retrieves TLSA. Proceed to a mutually
authenticated TLS session between the HNA and DM. At least the OI can
trust ownership of the FQN and the KSK. In case the HNA cannot be
authenticated, or the OI requires additional information, the OI may
provide a web interface for additional authentication.

The CPE sends a NS request associated to the Registered Domain over the
TLS session. This is different from a public DNS resolution. The NS
returned are those the OI will provided for outsourcing the zone.

The CPE also sends a DNS update for primary.<Homenet Registered
Domain>, with its WAM interface. No error is understood by the HNA as a
commitment from the OI to serve as a secondary.

THE CPE retrieves the Public Homenet Zone using AXFR over the TLS
session. An NXDOMAIN is interpreted as the zone has not been populated.

The CPE is able to outsource the potential DNSSEC zone.

--- ability to generate the Public Homenet Zone

The CPE re-populate of use the AXFR response to populate the Public
Homenet Zone.

The zone is signed and a NOTIFY is sent to the DM.

=== scenario

Potential parties are: end user, registrar, oi, manufacturer. While
coordination of independent parties should be feasible, that one actor
plays multiple roles or have pre-arranged some configuration should
simplify the configuration from the end user point of view. Here are
some envisioned scenarios

A manufacturer set a "specific" agreement with oi.com to host domain
names. To ease the process, the manufacturer could provision:
* Homenet Registered Domaine: (agreed between the manufacturer, registrar
and oi)
* DM with oi.
* default value identity (X509) KSK (pub, private) (eventually shared
between manufacturer and oi.

I have bought a box that is using oi.org. The CPE is configured with:
* well known DM
* UI askes user to pick Homenet Registered Domain Name.

I have a specific Homenet Domain Name, the registrar may provide me an
interface to provide the identity, DM for that registrar.

I am subscribing to a oi.com and regsitrar.com that have no agreement.
The issue is not different from hosting the zone to another party
(updating DS, NS). Eventually CNAMing could be an option.

On Sun, Jun 9, 2019 at 7:52 AM Ray Hunter (v6ops) <[email-masked]> wrote:

> 1) HNA is pre-configured with one or more DNS outsourcing providers in the
> admin GUI e.g. <example.com>.
>
> User picks one via LuCI.
>
> 2) HNA is pre-configured with one or more DNS outsourcing providers in the
> GUI e.g. <example.com>.
>
> User picks one via LuCI.
>
> 3) HNA owner purchases a nice name from a registrar e.g. <me.mydomain.com>.
> Domain Registrar and the DNS Outsourcing Infra example.com, don't share a
> common parent zone.
>
>
> On the other hand, the outsourcing infrastructure needs to know the fqdn
> of the hna. One way to provide that information could be to re-use DNS
> update updating the SOA of hna.example.com <http://hna.example..com>. The
> fqdn of the hna would be indicated using the MNAME field. Does it sounds
> reasonable as well ?
>
> Yours,
> Daniel
>
>
>
>
> homenet mailing [email-masked]://www.ietf.org/mailman/listinfo/homenet
>
>
> --
> regards,
> RayH
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jun 2019 11:03:59 -0400

On Jun 18, 2019, at 10:56 AM, Daniel Migault <[email-masked]> wrote:
> I am also questioning on whether we should provide some sort of recommendations for the UI. While we are not UI designers, I believe some properties could be interesting for designers, and those may be helpful to be provided. 

The trouble that we have gotten into repeatedly in this working group is that we write the specification in anticipation of an implementation, rather than on the basis of experience doing an implementation.   We have a fantastic testbed for this: OpenWRT.   I am at this point somewhat expert in doing OpenWRT builds.   Rather than speculating about what we need to say, why not do an implementation, see how it works, and then do a writeup based on what we learned?   We’re already talking about doing this at the Hackathon.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 18 Jun 2019 17:12:48 +0200

> Op 18 jun. 2019, om 17:03 heeft Ted Lemon <[email-masked]> het volgende geschreven:
> 

Running code is always a good teacher
Sander

---

From: Daniel Migault <[email-masked]>
Date: Tue, 18 Jun 2019 11:14:48 -0400

I agree, however,  think that we are moving toward what we want to
implement, though with various level of integrations. My point was that we
come with a description that works for different use cases and extensions.
Yours,
Daniel

On Tue, Jun 18, 2019 at 11:04 AM Ted Lemon <[email-masked]> wrote:

> The trouble that we have gotten into repeatedly in this working group is
> that we write the specification in anticipation of an implementation,
> rather than on the basis of experience doing an implementation.   We have a
> fantastic testbed for this: OpenWRT.   I am at this point somewhat expert
> in doing OpenWRT builds.   Rather than speculating about what we need to
> say, why not do an implementation, see how it works, and then do a writeup
> based on what we learned?   We’re already talking about doing this at the
> Hackathon.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jun 2019 11:27:52 -0400

On Jun 18, 2019, at 11:14 AM, Daniel Migault <[email-masked]> wrote:
> I agree, however,  think that we are moving toward what we want to implement, though with various level of integrations. My point was that we come with a description that works for different use cases and extensions. 

We should definitely come up with a list of things to try.  I’m just saying that without any experience, these will be pure conjecture, and hence not that useful.

---

From: Daniel Migault <[email-masked]>
Date: Tue, 18 Jun 2019 11:47:44 -0400

The question to the WG is whether this worth being tried, or if we are
missing something. Any thoughts, feed back would be appreciated.

Yours,
Daniel

On Tue, Jun 18, 2019 at 10:56 AM Daniel Migault <[email-masked]>
wrote:

>> Domain Registrar and the DNS Outsourcing Infra example.com, don't share
>> a common parent zone.
>>
>>
>> update updating the SOA of hna.example.com <http://hna.example..com>.
>> The fqdn of the hna would be indicated using the MNAME field. Does it
>> sounds reasonable as well ?
>>
>> Yours,
>> Daniel
>>
>>
>>
>>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jun 2019 11:51:43 -0400

On Jun 18, 2019, at 11:47 AM, Daniel Migault <[email-masked]> wrote:
> The question to the WG is whether this worth being tried, or if we are missing something. Any thoughts, feed back would be appreciated. 

The way such feedback is generated is through experience…

I happen to think that it’s worth at least talking about how this information is managed, and talking about what a management API would look like should be in scope.   Talking about what the UI should look like that sits on top of that API?   Out of scope.