Re: [homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-21: (with DISCUSS and COMMENT)

[Daniel Migault <[e-mail]>]

Thanks Roman for the follow-up. For some reason I could not find the
response.

So let me start with the initial question that was. Why do we have: The
Homenet Resolver SHOULD request the Homenet Authoritative Server... as
opposed as The Homenet Resolver MUST request the Homenet Authoritative
Server.

To start with, the core of the document is how the Homenet Authority (HNA)
and the Distributed Manager (DM) interact between each other, that is the
negotiation that leads to the HNA being configured as a primary DNS server
and the DM acting as secondary server. This ends up publishing the Public
zone.

The purpose of the architecture section is to show where this relation
happens within the homenet. For that purpose we did represent a number of
naming entities that can be present in the homenet. The architecture in
itself is not normative and we do not mandate that any home network (MUST)
have all these entities. Typically with one CPE all these entities are
likely to be combined and not all of them might be present.

You are absolutely correct that if we do want to provide some resilience
against the ISP disruption,  the Homenet Resolver MUST request the Homenet
Authoritative Server. The question is how realistically this can be
deployed, and we need to balance a minimal implementation that ensures some
"acceptable" resilience versus a mechanism that ensures a complete
resilience against the ISP network interruption.
Suppose that in the worst case, there is no Homenet Authoritative Server,
and the resolver gets all its responses from querying the  Public Homenet
Authoritative Server, only the first request (every TTL) goes outside.
Others are handled by the cache. Some may argue this achieves some sort of
resilience which might be enough especially as nothing needs to be done.
Some other implementations may be doing a bit more but may not be willing
for example to run a server for that only purpose and prefer to simply
cache a zone (the one of the HNA) in the resolver, perform an axfr to the
Public Homenet Authoritative Server and cache it. This could assume some
resilience that some vendors might consider acceptable. In this case there
will be no Homenet Authoritative Server, which makes it hard to require the
Homenet Resolver to request that entity.
In these latest cases, we do not have any queries leaking outside the home
network.... but we do not achieve a complete resilience toward ISP
disruption.
In fact, DNSSEC makes being completely resilient really challenging as most
DNSSEC clients have the root KSK as a Trust Anchor, and the chain of trust
for the root zone to the homenet zone (including the Delegated Signature)
need to be taken from outside the homenet. The other way around is to have
clients being configured with a homenet TA, but we are not there yet. This
is the case with the Homenet Authoritative Server being present also.

This is my understanding of what Michael pointed out as trade-offs. Now as
mentioned earlier the document provides an architecture overview to
position the functionalities between each other as to mandate it to be
implemented. This is why we do not go beyond the recommendation level
SHOULD. We also believe that anything beyond the scope of the protocol
between HNA and DM is out of scope of the document.

Now going back to the question pre-homenet and homenet. With pre-homenet I
understand the use of DynDNS.
I am not mentioning the protocol aspect where there are multiple ways to
handle it where HTTP is a very common way to handle this [1][3] and the
recommended way by DynDNS to handle this [3].
It is correct that - at least dyn - makes it possible to update via DNS
update and TSIG [4] (integrity but no confidentiality). TSIG is also using
a pre-shared key which comes with its own distribution issues.
Let's assume that DNS update + TSIG is used. updates are performed on a per
record level only the IP address of the device is updated.
While all devices could work independently as so being configured
individually (with the PSK), we can also consider a device like a CPE that
will update on behalf of most devices their respective IP address.

With homenet, the granularity is the zone (the Homenet zone) not a
specific RRset ( IP address). Centralization is performed by design
which enables DNSSEC signing. The centralization together with the use of
standard DNS functionalities also eases the publication of the zone inside
the home network - the Homenet Authoritative Server as well as the
publication of a DNSSEC zone. In general having standard protocols eases
the evolution of the naming architecture itself. Homenet is using TLS which
provides privacy - currently everything is in clear with TSIG. Key
distribution using Public key versus PSK is also seen as an advantage.
Homenet is using the standard DNS mechanism to update a Zone AXFR/IXFR as
opposed to a combination of DNS Update..

If you had an independent device sending its update A to the DNS provider,
one way to integrate this mechanism with homenet would be to make it update
the  zone hosted by the HNA which then syncs it with the DM. Such an
intermediary step ensures some resilience as opposed to the case where only
the public server is updated.

Back to your comments:

Pre-Homenet

DNS resolution for clients on the home network to access a home network
server:

-- … visible outside of the home network: NO


DynDNS is updating the DOI directly so the changes seem to be visible from
outside of the home network.


-- … usable if CPE-to-carrier link goes down: YES

In this case, if the link goes down the DNS resolution can be performed as
long as there is an entity in the network that makes such a resolution
possible. This is almost impossible if you only have independent devices
updating their own IP address. On the other hand if one centralized
managing the update, this is likely to be resilient to ISP disruption.


Homenet

DNS resolution for clients on the home network to access a home network
server:

-- … visible outside of the home network: YES

-- … usable if CPE-to-carrier link goes down: NO


With Homenet the name will be visible outside of the network as well.
Similarly, Homenet makes it very likely to be relient to ISP disruption as
homenet IS BY DESIGN centralized.


One point maybe is that in both cases DynDNS or Homenet is published names
that are intended to be published - only.


I apologize for being so long, and I hope that clarified your concerns.

Yours,
Daniel

[1] https://en.wikipedia.org/wiki/Dynamic_DNS
[2]https://help.dyn.com/remote-access-api/perform-update/
[3]]https://help.dyn.com/update-client-faqs/
[4] https://help.dyn.com/tsig/












On Thu, Nov 3, 2022 at 1:35 PM Roman Danyliw <[e-mail]> wrote:

> Hi!
>
>
>
> Please see an response to below to Michael’s email:
>
>
>
> *From:* Daniel Migault <[e-mail]>
> *Sent:* Monday, October 31, 2022 9:02 AM
> *To:* Michael Richardson <[e-mail]>
> *Cc:* Roman Danyliw <[e-mail]>; The IESG <[e-mail]>;
> [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Subject:* Re: [homenet] Roman Danyliw's Discuss on
> draft-ietf-homenet-front-end-naming-delegation-21: (with DISCUSS and
> COMMENT)
>
>
>
> Hi Roman,
>
>
>
> This is just a follow-up. Currently we believe we have addressed your
> concerns, but we would like to double check if there are any other
> concerns/questions you would like us to address.
>
>
>
> Yours,
> Daniel
>
>
>
> On Thu, Oct 27, 2022 at 3:43 PM Daniel Migault <[e-mail]>
> wrote:
>
>
>
>
>
> On Thu, Oct 27, 2022 at 5:32 AM Michael Richardson <[e-mail]>
> wrote:
>
>
> Roman Danyliw via Datatracker <[e-mail]> wrote:
>     > [per -18] I’m not sure if this my misreading of the behavior of
>     > internal clients.  To clarify, the (internal) Homenet DNSSEC Resolver
>     > will “... resolves the DS record on the Global DNS and the name
>     > associated to the Public Homenet Zone (myhome.example) on the Public
>     > Authoritative Servers.”?  Why would the internal resolver serving a
>     > request for an internal client for an internal service go to the
> Global
>     > DNS if the information if it could come from the internal Homenet
> Zone
>     > it is already configured with?
>
> Because it needs the glue records to prove it is authoritative.
>
> There are cases - quite common - where the Homenet Authoritative server
> does not exist. In such cases, the Homenet Resolvers just caches what is
> published outside.
>
>
>     > As an operational consideration, why go
>     > outside of the network if you don’t need to?  As a privacy
>     > consideration, why leak the request to an outside entity if the
> network
>     > already has the information.
>
> We do mention in the version 21 that going outside has some privacy
> implications. Note also that the resolver only goes outside once the TTL
> has exceeded so that is not every time a DNS request is received.
>
>
>
>     > [per -20] Thanks for the revised text: On the other hand, to provide
>     > resilience to the Public Homenet Zone in case of WAN connectivity
>     > disruption, the Homenet DNSSEC Resolver SHOULD be able to perform the
>     > resolution on the Homenet Authoritative Servers.
>
>     > -- Is there a reason this can’t be a MUST?
>
> If the resolver and cache have been offline for long enough, any cached
> chain
> of DS/NS/DNSKEY records from . down to the myhome.example might have
> expired.
> (Consider a DNSSEC resolver on a host behind the gateway)
>
> What to do in this situation has many answers with different tradeoffs.
>
> Yes. answers and tradeoffs are indeed quite numerous and we can hardly go
> beyond such a recommendation. Consider that the homenet an authoritative
> server may not exist or the Homenet Naming Authority may play multiple
> roles. Also keep in mind that our document is mostly focused on the Homenet
> Naming Authority and Distributed Manager, not so much on the naming
> architecture of the home network. As a result, strong recommendations
> regarding the resolver may be a bit out of scope of the document.
>
>
>
>
>
> [Roman] I’m not sure that I follow all of the trade-offs. Let me try to
> restate things at a higher-level.
>
>
>
> “Pre-HOMENET”
>
> Without HOMENET, home users relied on a approaches such as those described
> in Section 1.2 of -18 of this draft (this text has now been removed).  One
> way I understood such configurations to work is that you might use dynamic
> DNS to map the carrier provided publicly routable IP address to a
> hostname.  With IPv4, the CPE would then do “port forwarding” for that
> service to be accessible remotely since the home network likely only got
> one IP address.  With IPv6, the home network would get a prefix so the
> machines behind the CPE would each have publicly routable IP addresses.
> CPEs might also provide an internal resolver to answer for the names
> assigned to the devices on the home network to serve users on the home
> network.
>
>
>
> DNS resolution for clients on the home network to access a home network
> server:
>
> -- … visible outside of the home network: NO
>
> -- … usable if CPE-to-carrier link goes down: YES
>
>
>
> “HOMENET solution”
>
>
>
> With all of the proposed roles and flexibility in the architecture, isn’t
> there increased visibility of previously private network behavior and
> reduced resiliency.
>
>
>
> DNS resolution for clients on the home network to access a home network
> server:
>
> -- … visible outside of the home network: YES
>
> -- … usable if CPE-to-carrier link goes down: NO
>
>
>
> I’m wondering if this name delegation approach could be deployed in a way
> to keep the “Pre-HOMENET” properties as described above?
>
>
>
> Roman
>
>
>
>
>
>

-- 
Daniel Migault
Ericsson