Hi Stephen, Thanks for the questions / suggestions / comments. Please find some responses inline. I updated the document [1] and added issues on the git repo.
Yours, Daniel [1] https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/cc07384cf6a93794f984d3393100e700a306317c#diff-1fb3d4609e8b03755bf2390df10a5ccd792f989796a0b922a273cd63418fcaa5 On Mon, May 24, 2021 at 5:01 PM Stephen Farrell <[email protected]> wrote: > > Hiya, > > I had a read of this one. My comments (as an individual, not > as chair) below. I'll chat with Barbara to see if we have a > common position on how to handle next steps but am happy to > chat about stuff below whenever. > > Cheers, > S. > > review of draft-ietf-homenet-front-end-naming-delegation-15 > sf, 20210524 > > general/technical: > > #1 This needs significant editorial work, there are too many > grammatical issues, at least some of which lead to ambiguity. > > #2 If a home network/CPE isn't robust enough to serve as a DNS > server for it's public zone, then how is it robust enough to > resist attack/DoS on the addresses exposed in that zone? That > seems to me to counter a bunch of the arguments for this > approach, so I'd like to understand the proponents arguments > there. At minimum, any AAAA for an "inside" server/name means > that the CPE's f/w will be subject to the same kind of attacks > that might happen if the CPE was the only/primary DNS server > for the zone. > > <mglt> CPE are optimized for packet l2/l3 packet switching as opposed to terminate services. Resources of the CPE are estimated for volumetric attacks that are expected to be handled by the ISP. Hosting DNS changes the scope on that the CPE becomes an addressable target, subject to application DoS attacks which it has not been in general designed for and which are much harder to tackle for an ISP as this is "legitimate" traffic. The document does not specify the HNA is addressable from inside the network and Figure 1 clearly separates the authoritative server from the HNA. Of course this could be implemented this way, but I am wondering if there is any text that suggests such an approach. It seems to me that discussion over the management of the authoritative DNS server on the CPE is out of the scope of the document. In addition, if an DDoS attack is handled from inside the homenet, the network admin is more likely to unplug that device than if performed from the Internet. </mglt> > #3 The arguments about handling "disruption with the ISP" could > do with some more evidence, not necessarily as text in the > draft, but it ought exist - does it? E.g. do we know that > publishing ULAs isn't problematic? Do we know that GUAs in such > scenarios aren't still usable for longish durations given a > realistic pattern of ISP disruption? > > <mglt> ISP disruption is not an argument but a requirement from RFC7368 section 3.7.5. I think we all experience some connectivity disruption, so I do not believe there is a need to clarify this exists. The most obvious case is equipment that goes down for some time. A transition from one ISP to another seems to me a bit out of scope of the document. The document considers renumbering which could be a good start for a more complex management transition, that sounds to me very specific and out of scope of the document. We have added a section in the security consideration that I think covers your concern: """ The HNA enables to handle network disruption as it contains the Public Homenet Zone, which is provisioned to the Homenet Authoritative Servers. However, DNSSEC validation requires to validate the chain of trust with the DS RRset that is stored into the parent zone of the Registered Homenet Domain. As currently defined, the handling of the DS RRset is left to the Homenet DNSSEC resolver which retrieves from the parent zone via a DNS exchange and cache the RRset according to the DNS rules, that is respecting the TTL and RRSIG expiration time. Such constraints do put some limitations to the type of disruption the proposed architecture can handle. In particular, the disruption is expected to start after the DS RRset has been resolved and end before the DS RRset is removed from the cache. One possible way to address such concern is to describe mechanisms to provision the DS RRset to the Homenet DNSSEC resolver such as HNCP for example. Such work is out of the scope of this document and is left from future work. """ Similarly, the zone content is also a bit out of scope of the document and the admin is supposed to be responsible for what he is publishing. The text mentions the publication of ULA with a may, as an example. I think it is useful to have this as a consideration but elaborating on this may end up in a complete book of managing the homenetwork, which I do not think is the purpose of this - already long - document. Removing the text would not affect the scope of the document, but I think it is useful information to avoid some mis-conceptions. </mglt> #4 My home network is IPv6 renumbered every time there's a > reboot/power outage at the DSLAM, which happens maybe twice a > year. How would this protocol handle that? Would the DM get > overloaded maybe? > > <mglt> As per RFC 8415, 7291, I expect CPE are gradually brought up. However, assuming such a crowd event happens, it seems reasonable to assume the DM is able to deal with DNS SERVFAIL, TLS internal_error, TCP RST, HTTP 503... I see this as a standard service provided by any cloud provider. It is also unclear to me how this is different from all CPE reconnecting to a common service/app such as Google Mail for example. I do not think additional text is needed here, but maybe you would like something being added into the Security configuration. Is that what you had in mind ? </mglt> > #5 The arguments why this is better than DDNS don't convince > me, except for the last one (new RR types). Given that DDNS is > deployed, what's the chances that this would also get traction? > (Not asking that all be in the document, but I am asking.) > > <mglt> To me scalability a standard interface for (any) DNS RRSet that is scalable is the most convincing argument. Currently Dynamic DNS consists of multiple distinct protocols. [1] lists 11 of them, I am not sure Gandi has been included either [2], not all versions are using TLS. Their usage is mostly intended for a single or a very limited number of RRsets. The HNA seems more appropriate for a home network. For example, if all devices have a client, all devices need to be manually provisioned every time you change your homenet domain, every time your account/provider changes... which hardly scales. [1] https://ddclient.net/protocols.html [2] https://github.com/rmarchant/gandi-ddns </mglt> #6 Do the DM/DOI care about the names published? If not, why > not? E.g. say an ISP has the DOI servers "first" in how it > resolves names for a local area, what'd stop some home from > claiming to be windowsupdate.com? > > <mglt> The situation is similar as today, the DOI needs to have some guarantees you really own the domain. The DOI is expected to be a sort of registrar which could be limited to owning a domain. In the example windowsupdate.com I hardly see .com doing the delegation to the DOI without strong evidence that the DOI owns windowsupdate.com. To me this looks obvious, so we may have underestimated this aspect. I have opened an issue, to carefully address this. If you have any text you would like to see, please feel free to propose it. https://github.com/ietf-homenet-wg/ietf-homenet-hna/issues/51 </mglt> #7 If the DOI sends the DS to the parent, then the DOI can > cheat on the home - why is that ok? If it is ok, then shouldn't > there really be a MUST for the HNA to check that the correct DS > is/was published via some recursive outside the control of the > DOI? > > <mglt> It is unclear to me if you are referring to a specific paragraph in the document, but it is likely that the CPE will perform some kind of checks and a DNSSEC resolution to a domain it owns is likely to be done. Sure the DOI may cheat, but if that is the case, the DS will hardly provide any significant protection as the DOI may still respond non DNSSEC to user users than the homenet. This will make it hard to detect. I currently do not see this as a major threat, but I might be missing something. </mglt> #8 Do the DS TTL and RRSIG expiry times set the limit for how > long the home n/w can handle ISP disruption? If so, be good to > say so. I also wonder if that limits the added-value here or > not. > > <mglt> Currently the DS puts some limit to the ISP disruption, but section 3.1 mentions that other mechanisms to enable resolutions to the DNS authoritative servers may be designed in the future. This specification does not change the DNS, nor create HNCP mechanisms. If future usage requires it, specific handling will need to be defined. To my perspective, such mechanism We added some specific text in the Security Consideration ( see above regarding the disruption). </mglt> #9 Requiring mutually authenticated TLS between HNA and DM > (section 3.2 has that MUST, even if it says TLS is only > RECOMMENDED), seems like a circular dependency. How does the > HNA get that client-cert before/at the start? > > <mglt> I am reading the following text in section 3.2 where we mandate a mutually authenticated communication and recommend TLS among the other protocols that can do that. I suspect you added "TLS" when we mentioned mutually authenticated, but we may also have made a mistake, so please let us know. """ The entity within the DOI responsible to handle these communications is the DM and communications between the HNA and the DM MUST be protected and mutually authenticated. While Section 4.6 discusses in more depth the different security protocols that could be used to secure, it is RECOMMENDED to use TLS with mutually authentication based on certificates to secure the channel between the HNA and the DM. """ There are two common cases to get the client cert. The first one is out-of band configuration. The second is using a self signed certificate when the ISP for example identifies the lines. We believed it was better to mandate mutually authenticated users at all times to avoid multiple versions / capabilities of the HNA. </mglt> #10 4.x: I don't understand how we get interop based on all > this. Wouldn't this kind of thing need a bunch of people to > have implemented and interop'd before we could be confident of > the spec? > > <mglt> I think this statement overestimates the complexity. The exchanges described are fairly standard and the space for confusion is limited. We have an implementation which I think is sufficient. The apparent complexity may come from the use of NSUPDATE itself that we are less familiar with than AAAA. </mglt> #11 I don't understand what problem we're really solving with > the reverse zone stuff, nor do I see the overall thing here > would work where the ISP provides those reverse-IP stanzas for > a zone file but where that ISP has no way to update the > parent's DS record. Are there a set of "just doens't work" > configurations there really? If so, shouldn't that be either > stated or solved somehow? > > <mglt> I do not understand the comment. I suppose the ISP owns the prefix it is delegating. Please point me to the text that is confusing, I am happy to clarify it. </mglt> #12 Section 10 seems like a mix of generic guidance and > requirements but also things needed for interop (e.g. use DoT > on 853). I'm not convinced that's a good plan if we want > multiple implementations that interop. > > <mglt> I think that section 10 and 14 may be merged together. On the contrary, I see that defining default values and parameters will help interoperability. I have created the following issue: https://github.com/ietf-homenet-wg/ietf-homenet-hna/issues/48 </mglt> specific/editorial: > > - abstract: "often" where's the evidence for that? Why do you > even need to make that (questionable) assertion? Better to > just set out the mechanism. > > <mglt> correct. often has been removed. </mglt> > - abstract: "using names" should probably be "using DNS names > or similar" > > <mglt> I am fine changing this to DNS names. The reason for having names here was that most people using these names do not even know they are using DNS names. In other words, the motivation is more on the names than the use of DNS. Changed to DNS names. </mglt> > - abstract: documents don't "automate" things > > <mglt> changed to : """This document describes how to automate the process through...""" </mglt> > - abstract: "servers" - you don't know, and shouldn't require > that, the FQDNs published are those of servers. > > <mglt> The servers in questions are the DNS servers the text is changed to: """This document describes how to automate the process through the creation of a Homenet Naming Authority (HNA), whose responsibility is to select, sign and publish DNS names to a set of publicly visible DNS servers.""" </mglt> > - abstract: "the naming service" - what's that exactly? Isn't > this just a new flavour of feeding zones to a DNS > authoritative? > > <mglt> The naming service of a homenet is the ability to respond to (DNS) names that corresponds to the homenet. Changed to: """the home network naming service.""" </mglt> - 1.0: what is "a single universal view"? Are you contrasting > that with split horizon or something? > <mglt> The intent is to mention that all representations publicly available are expected to be in this Zone. This contrast with DNS split as well as various possible resolutions, discovery mechanisms that could be used. </mglt> > > - 1.1: Publishing ULAs because of a VPN seems like an odd > justification. Seems more likely a VPN could/would set a > different DNS recursive for clients and ULAs could be handled > there. > <mglt> Apparently this is a use case people had, but it is also important in my view to mention that the type of address does not define the type of resolution / discovery mechanism. </mglt> > > - 1.2: that might be better as an appendix or deleted. It's > probably a bad idea to name specific commercial DDNS > services. > > <mglt> We removed Dyn, Gandi and added the ddclient link to DDNS. </mglt> > - section 2: "DOI" isn't a good choice - every RFC has one of > those and it's not what's defined here:-) If you could avoid > the acronym collision that'd be better. Maybe "domain name > outsourcing infrastructure"/DNOI? > > <mglt> Correct. I opened the issue: https://github.com/ietf-homenet-wg/ietf-homenet-hna/issues/49 </mglt> > - section 2: I'm not seeing why you need (new?) terms for types > of recursive resolver. Aren't those already defined > elsewhere? > > <mglt> The two resolvers are defined below: The two resolvers proceed differently, so it seems to us clearer to position and define them clearly. I do not think we would have a common understanding with terms defined elsewhere. Typically, some resolvers resolve internally while others do not. The term public resolver is often used but also raised some discussions. """ Homenet DNSSEC Resolver: a resolver that performs a DNSSEC resolution on the home network for the Public Homenet Zone. The resolution is performed requesting the Homenet Authoritative Servers. DNSSEC Resolver: a resolver that performs a DNSSEC resolution on the Internet for the Public Homenet Zone. The resolution is performed requesting the Public Authoritative Servers. """ </mglt> > - 3.1: I have no idea what is meant by: " The ".local" as well > as ".home.arpa" are explicitly not considered as Public > Homenet zones and represented as Homenet Zone in Figure 1." > That seems like an important thing to be clear about. > > <mglt> Changed to: """ [...] and are represented as Homenet Zone in Figure 1.""" </mglt> - 3.1: How is backup of KSK/ZSK handled? That's needed in this > scenario as CPE kit breaks or is discarded. That might or > might not be something needing protocol but it definitely needs > mention. > > <mglt> I do not think that this should be mentioned in the architecture overview section as no mention of the ZSK/KSK have been made. We add the following section in the security consideration """ ## Operational Considerations The HNA is expected to sign the DNSSEC zone and as such hold the private KSK/ZSK. To provide resilience against CPE breaks, it is RECOMMENDED to backup these keys to avoid an emergency key roll over when the CPE breaks. """ </mglt> > - 3.2: What DoX implementation supports TLS client auth? > > <mglt> BIND and Unbound uses OpenSSL which supports client authentication. Note that the DM can be implemented with a limited set of exchanges. </mglt> > - 3.2: I don't get why a single IP/port is needed for the DM. > > <mglt> We did not provide the ability of the DM to be configured as a secondary on a different IP address than the one used . Similarly we also wanted the synchronization channel and the control channel to use the same protocol. This was believed to bring unnecessary complexity. Such capabilities may be added in the future. </mglt> > > - 4.5.1: "MUST send a DNS request of type AXFR associated to > the Registered Homenet Domain" - what if the domain is > already used/populated/whatever? > > <mglt> This AXFR is just to retrieve the configuration parameters the DOI expect to appear in the Public Zone. These parameters are expected to remain stable, and regularly checked by the HNA. </mglt> > - 4.5.1: Where else is there the concept of a "zone template"? > If nowhere else then I wonder if that concept needs some more > review? (I can well imagine how to make a zone file template > and am sure many have done so, but I bet there are corner-cases > galore.) > <mglt> The DNS template is used to carry some specific information and explicitly lists how this information is carried. I do not see corner cases. It is not a template that is globally applied. The reason we designate it as a template is that these parameters are likely to be reused by all clients. </mglt> > > - section 5: What are YYYY, ZZZZ and XX supposed to be? At > least XX seems to require an IANA action or the re-use of > some port number? > > <mglt> YYYY and ZZZZ designate a high port range and XX designates the port associated to well known port. These port are not defined in this specification. In this specification XX is likely to designates DoT. The reason for using the letters is to clearly explain that the Control Channel and Synchronization Channel cannot be mixed. The following text should clarify the concern: """ The DM Synchronization Channel is used for communication between the HNA and the DM for synchronizing the Public Homenet Zone. Note that the Control Channel and the Synchronization Channel are by construction different channels even though there they may use the same IP address. Suppose the HNA and the DM are using a single IP address and let designate by XX, YYYY and ZZZZ the various ports involved in the communications. In fact the Control Channel is set between the HNA working as a client using port number YYYY (a high range port) toward a service provided by the DM at port number XX (well known port such as 853 for DoT). """ </mglt> > - 5.1: It's not clear that DANE will always be ok there - there > should be a way to make it work but I don't think I've seen > any worked-out description of using DANE for DoX. > > <mglt> The intention of the text is to mention that other mechanisms can be used. DANE is only used to carry the certificate. </mglt> > - 5.1: "baked-in" isn't right - typically those lists are > updated by the OS (e.g. OpenWRT) or via application s/w > update. (My nearest OpenSSL install has an /etc/ssl/certs > directory.) > <mglt> In this case I imagine the certificate being specific to the HNA (application) and provisioned as a sort of TA, CA... In particular I do not think the backed-in should be used for any other purposes. I opened an issue to clarify that point. https://github.com/ietf-homenet-wg/ietf-homenet-hna/issues/50 </mglt> > > - 5.1: I'm not clear how exactly pinning via tickets would work > here but I didn't read RFC8672 just now so maybe it's all > clear from tha - is it? > > <mglt> This is to ensure that the DM you started with remains the same one across the exchanges. </mglt> - section 9: I don't understand: "This leave place for setting > up automatically the relation between HNA and the DNS > Outsourcing infrastructure as described in > [I-D.ietf-homenet-naming-architecture-dhc-options]." > > <mglt> The ISP manages a DOI for the IP prefix domain name, identifies the line to which the IP prefix is assigned which makes out-of band configuration of the client unnecessary. Without such out-of-band step, the process can be completely automated. </mglt> > - section 9: "2001:db8:babe:0001::2" - the string "babe" has > both innocent and less innocent interpretations, not sure if > you want to risk the latter being some reader's interpretation. > > <mglt> Thanks. You are correct I prefer not to take the risk. When reading I did not go further than it is a word and the one I know is a kid's movie, so I did not pay attention. I changed it to aeae. </mglt> - section 10: you use a different example here from earlier, > just one is probably better, unless there's a reason they > ought differ. > > <mglt> Changed to myhome.example. Thanks. </mglt> > - 11.1: is a subsection needed there really? (I kinda skipped > all that text TBH;-) > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
