Re: [homenet] primary / secondary configuration

[Daniel Migault <[e-mail]>]

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 <[e-mail]>
wrote:

> 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) <[e-mail]>
> wrote:
>
>>
>>
>> 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 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 using the MNAME field. Does it
>> sounds reasonable as well ?
>>
>> Yours,
>> Daniel
>>
>>
>>
>>
>> _______________________________________________
>> homenet mailing [e-mail]://www.ietf.org/mailman/listinfo/homenet
>>
>>
>> --
>> regards,
>> RayH
>>
>> <https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
>> _______________________________________________
>> homenet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/homenet
>>
>