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. #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? #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? #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.) #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? #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? #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. #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? #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? #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? #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. 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. - abstract: "using names" should probably be "using DNS names or similar" - abstract: documents don't "automate" things - abstract: "servers" - you don't know, and shouldn't require that, the FQDNs published are those of servers. - abstract: "the naming service" - what's that exactly? Isn't this just a new flavour of feeding zones to a DNS authoritative? - 1.0: what is "a single universal view"? Are you contrasting that with split horizon or something? - 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. - 1.2: that might be better as an appendix or deleted. It's probably a bad idea to name specific commercial DDNS services. - 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? - section 2: I'm not seeing why you need (new?) terms for types of recursive resolver. Aren't those already defined elsewhere? - 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. - 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. - 3.2: What DoX implementation supports TLS client auth? - 3.2: I don't get why a single IP/port is needed for the DM. - 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? - 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.) - 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? - 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. - 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.) - 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? - 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]." - 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. - section 10: you use a different example here from earlier, just one is probably better, unless there's a reason they ought differ. - 11.1: is a subsection needed there really? (I kinda skipped all that text TBH;-)
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
