Paul Wouters has entered the following ballot position for draft-ietf-homenet-front-end-naming-delegation-25: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the updated document. It is much clearer now which parts are specified and which parts are out of scope. The repeated clarifications with primary/secondary also makes the document much easier to read. I have a few discuss items left to resolve. Other than the Document Status also raised by others, I think the DISCUSSes should be easy to resolve. #1 Document Status As other ADs have pointed out, Standards Track would not be the right intended status. Experimental would be a much better fit. I understand this is done because otherwise 3gpp won't consider the document, but whether the IETF should make its decisions based on that is something I'd like to discuss with the other members of the IESG. #2 Security Considerations for DM/DOI missing There is no Security Considerations paragraph for the DM/DOI ? For example, if I want to use "ietf.org" for my Public Homenet Zone, that should probably not be allowed to be served by the ISPs DM/DOI infrastructure. Similarly, currently non-existing domains like "mailietf.org" or TLDs should probably not be allowed. When allowing subdomains of existing registrations, perhaps it can recommend the DM/DOI does a verification check, eg via draft-ietf-dnsop-domain-verification-techniques #3 Conveying the name of the zone to use The HNA builds the Public Homenet Zone based on a template that is returned by the DM to the HNA. Section 6.5 explains how this leverages the AXFR mechanism. If it uses AXFR, I guess the name itself cannot be part of the template and has to be handled differently. Unless it would use DNS catalog zones, eg draft-ietf-dnsop-dns-catalog-zones. Information on how to convey the name to be used as Public Homenet Zone should be added to Section 6.1. #4 HNA IP address As a result, the HNA must provide the IP address the DM should use to reach the HNA. Note there is an odd lowercase "must" here, which becomes stranger when later on it states: By default, the IP address used by the HNA in the Control Channel is considered by the DM and the explicit specification of the IP by the HNA is only OPTIONAL. So it seems the HNA doesn't need to "must provide", as its IP as visible by the DM/DOI is used anyway and providing it (explicitly) is deemed OPTIONAL ? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The description of what a Public Homenet Zone is a bit better, but I think it would be good to add a sentence somewhere saying it more concise, eg "The device assigned zone or user configurable zone to use as the domain to publicly serve hostnames in the home network is called the "Public Homenet Zone". In this document, "myhome.example" is used as the example for an enduser owned domain configured as Public Homenet Zone. After reading a few "Public Homenet Zone" names, I also didn't understand a sentence where it said "Homenet Zone" because it is so similar and I didn't realize for a bit that "Public" was missing. I'd recommend renaming "Homenet Zone" to "Private Homenet Zone" to make this more obvious (to both implementers and endusers) This is a zone transfer over TLS It would be clearer to call this to be over mutual TLS to distinguish it from DoH or Dot where the client does not authenticate itself at all. (other places did properly add a note about mutual auth) Revealing the address of the HNA in the DNS is not desirable. Is there an issue if this is revealed? How hard is it to find the HNA if you know any other IP from the Public Homenet Zone ? Should there be a Ssecurity Consideration for embedded DHCP/RA servers on how to assign IPv6 addresses to hide the HNA better from the user content? (if the NS are in-bailiwick [RFC8499]). The term "in-bailiwick" is being sunset for "in-domain", see https://www.mail-archive.com/dnsop@ietf.org/msg26229.html (this term appears more than once in the document) (a high range port) It is an ephemeral port. Those happen to be high in the valid range, but I would not call it "high port" as that is poorly defined (32768+ ? 55000+ ? etc) (another high range port) Same here. I would also change XXXX and YYYY to XXXXX and YYYYY as these would very likely be higher than 32768 and so would be 5 digits, not 4. and so DNS notifies are sent over the Control Channel, secured by TLS. mutually authenticated TLS. As this AXFR runs over a TCP channel secured by TLS mutually authenticated TLS. [RFC9103] makes no requirements or recommendations on any extended key usage flags for zone transfers, and this document adopts the view that none should be required, but that if there are any set, they should be tolerated and ignored. A revision to this specification could change this, and if there is a revision to [RFC9103] to clarify This is a weird way of saying, "EKU usage SHOULD follow the requirements of [RFC9103]" and leave it up to 9103 to get updated for this document's normative reference to be considered updated as well. (this appears twice in the document) The use of a TLS session tickets [RFC8446], Section 4.6.1 is RECOMMENDED. According to 2119, RECOMMENDED means SHOULD. I think that a SHOULD for using TLS session tickets is a bit strong. I could see that a setup like this might not need to communicate more than once every few days, in which case it is likely that the TLS session ticket has expired anyway. I think MAY would be more appropriate here. The DM SHOULD ignore the Pre-requisite and Additional Data sections, if present. Why is this not a MUST ? This document exposes a mechanism that prevents the HNA from being exposed to queries from the Internet. It does not "expose a mechanism" for that. It did offer some policy decisions on how to limit queries and drop certain ones. Which is re-iterated in the sentences immediately following this. I would remove this sentence. The DNSSEC keys are needed on an hourly to weekly basis, but not more often. This isn't entirely true, when devices' their IP addresses are being added, removed of modified. Perhaps add some weasel wording like "are generally needed on an ...." I find the term "home network operator" a bit misleading. We are really talking about endusers here, not qualified or licensed "operators". Some of the Security Considerations given to these "home network operators" seems rather technical. Instead, I feel the protocol really needs to protect the enduser from making mistakes. Perhaps the Security Considerations for them need to be tweaked to apply to the protocol and its implementers. Carriers may need to deploy additional mitigations to ensure that attacks do not originate from their networks. The use of RFC8520 (MUD) filters is one such method. I didn't think MUD was deployed by Carriers for in-home devices? Do you mean to say that Carriers could recommend CPE equipment and in-home devices that support the use of RFC8520 (MUD) filters ? Or do you envision MUD capable devices in the HomeNet actually get their MUD profiles enforced by the Carrier/ISP ? NITS: The DOI benefits from a cloud infrastructure while the HNA is dimensioned for home network and as such likely enable to support any load. Should that be "unable to support any load" ? This specification defines a mechanism that re-use the [...] that re-uses An error indicates the MD MD -> DM _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
