Re: [homenet] primary / secondary configuration

Daniel Migault <daniel.migault@ericsson.com> Tue, 18 June 2019 14:56 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A52712011C for <homenet@ietfa.amsl.com>; Tue, 18 Jun 2019 07:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X4xU5nSfE-k for <homenet@ietfa.amsl.com>; Tue, 18 Jun 2019 07:56:27 -0700 (PDT)
Received: from mail-vk1-f195.google.com (mail-vk1-f195.google.com [209.85.221.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232411200F4 for <homenet@ietf.org>; Tue, 18 Jun 2019 07:56:27 -0700 (PDT)
Received: by mail-vk1-f195.google.com with SMTP id 125so2884859vkb.4 for <homenet@ietf.org>; Tue, 18 Jun 2019 07:56:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v7/ec5I1VKZXtVIWW/c5q5C5i0B/iuwuTALQEBlr4BI=; b=Vs3CnLP5ueX8zFTA3QXfqFSXjQ4NP+4mTkLhVNxozooN7LOuM2NTzcY6WX1DX+iVFc XHd1orD9V+zhTML7MQPCsBoqunDTlPEa2NxwnYmClHas49VHkPH3tVGCOCATE6GroCHf /7xko0q2K96DLr4EIMj3+L6TeuOUyubzVx4gp43CMTE+20aNxNLW/vsK5egvBQau0le/ HUX1JLdbKVChGu9QfjpgF7OXiqLXMPnXJd2EVWjjhsCo1nq7FwxLYeQ/PNuJ3iTmyQIx Hee5oRh46cui/YApwuaCMZ1UJkVHWEqxKM6PkIc+Jk/mp1pFZaxMKAGS8rVnQt3Hxen5 hVQw==
X-Gm-Message-State: APjAAAX5F6/sp+3BEYJKbdMBGHLfw58mg2mvk+BMBJ7hxBN7QyDdCshI SJQK57qjjkP/zBFUC7admlkgygNl6vIqRoUBNgkNZGCqPfQ=
X-Google-Smtp-Source: APXvYqxjKL1finAx6rkJ65H0lw0TlTUMqulJqrlEUg0X9m7pp36cJsUMgBGOG5K8n5wypOUHji2L1PCnQ90hiSRGy/o=
X-Received: by 2002:a1f:ab04:: with SMTP id u4mr26869135vke.40.1560869785605; Tue, 18 Jun 2019 07:56:25 -0700 (PDT)
MIME-Version: 1.0
References: <CADZyTknGV8huQzVrQcJgFu82HGkOhBe9Q2f23bBXYT8-WOjtPg@mail.gmail.com> <07b0d046-1a1e-7019-49df-46a9470eab48@globis.net>
In-Reply-To: <07b0d046-1a1e-7019-49df-46a9470eab48@globis.net>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 18 Jun 2019 10:56:14 -0400
Message-ID: <CADZyTknZNOa9asX49DGbxKFpd1gkgHAkSxyeyH77zOfd__O=eg@mail.gmail.com>
To: "Ray Hunter (v6ops)" <v6ops@globis.net>
Cc: homenet <homenet@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001c994d058b9a515c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/gdUtsxSvaLpRpqft-H7NnrhCyGk>
Subject: Re: [homenet] primary / secondary configuration
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2019 14:56:31 -0000

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) <v6ops@globis.net> 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 listhomenet@ietf.orghttps://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
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>