Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt

[Stephen Farrell <[e-mail]>]

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;-)