Re: [homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-21: (with DISCUSS and COMMENT)
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
Re: [homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-21: (with DISCUSS and COMMENT)
Hi! Please see an response to below to Michael’s email: From: Daniel Migault Sent: Monday, October 31, 2022 9:02 AM To: Michael Richardson Cc: Roman Danyliw ; The IESG ; draft-ietf-homenet-front-end-naming-delegat...@ietf.org; homenet-cha...@ietf.org; homenet@ietf.org; stephen.farr...@cs.tcd.ie 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 mailto:mglt.i...@gmail.com>> wrote: On Thu, Oct 27, 2022 at 5:32 AM Michael Richardson mailto:mcr%2bi...@sandelman.ca>> wrote: Roman Danyliw via Datatracker mailto:nore...@ietf.org>> 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
