Hi Roman, I am just following up and I am wondering if there is anything that we missed to lift your DISCUSS ?
Yours, Daniel On Thu, Nov 3, 2022 at 9:48 PM Daniel Migault <mglt.i...@gmail.com> wrote: > 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 <r...@cert.org> wrote: > >> Hi! >> >> >> >> Please see an response to below to Michael’s email: >> >> >> >> *From:* Daniel Migault <mglt.i...@gmail.com> >> *Sent:* Monday, October 31, 2022 9:02 AM >> *To:* Michael Richardson <mcr+i...@sandelman.ca> >> *Cc:* Roman Danyliw <r...@cert.org>; The IESG <i...@ietf.org>; >> 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 <mglt.i...@gmail.com> >> wrote: >> >> >> >> >> >> On Thu, Oct 27, 2022 at 5:32 AM Michael Richardson <mcr+i...@sandelman.ca> >> wrote: >> >> >> Roman Danyliw via Datatracker <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 >> >> >> >> >> >> > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
