Hi Paul, Thanks for the review. We updated the document as follows. https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/63/commits/f221d3413f71bf95f8961f8fe3c71e53f8f3dd20
The only comment that has not been addressed is the one concerning the MUD. You can find inline my comments. Yours, Daniel On Sun, Jan 1, 2023 at 9:01 PM Paul Wouters via Datatracker < nore...@ietf.org> wrote: > 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 > > To my view, the protocol assumes the registered domain is legitimate, and this mostly because the HNA is authenticated. We do have a section that details ownership of the domain name is necessary. I think the draft you mention is a good fit in that section. I am not against mentioning this in the security consideration, but one thing that remains unclear to me is if I am asking the DOI to server ietf.org, as the NS in the parent will not be updated, the zone will only be known to me. Furthermore, I expect the DOI will realize very quickly the domain name is not legitimate. Then I am wondering if that is an issue. we have updated the text as follows: ## Registered Homenet Domain The DOI MUST NOT serve any Public Homenet Zone that it has not strong confidence the HNA owns the Registered Homenet Domain. Proof of ownership is outside the document and is assumed such phase has preceded the outsourcing of the zone. #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. > In our case, the template contains the registered homenet zone, so I agree with you that this is not a generic template, but a template being used by the HNA. > > Information on how to convey the name to be used as Public Homenet Zone > should be added to Section 6.1. > I think this is stated in the following text: """ The NAME of the SOA RR MUST be the Registered Homenet Domain. """ > > #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 ? > > I see your point. "must" here indicate that the DM needs to know the IP. OPTIONAL indicates the HNA may send it via a DNS exchange but the IP can also be taken from the control channel. We replace with the text below: """ As a result, the HNA needs to provide the IP address the DM should use to reach the HNA. If the HNA detects that it has been renumbered, then it MUST use the Control Channel to update the DOI with the new IPv6 address it has been assigned. The Synchronization Channel will be set between the new IPv6 (and IPv4) address and the IP address of the DM. 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. The transport channel (including port number) is the same as the one used between the HNA and the DM for the Control Channel. """ > ---------------------------------------------------------------------- > 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. > > We added the lines. > 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) > > We had this terminology at some point and removed it as it was confusing since the Private Homenet Zone has some communalities with the Public Homenet Zone. At that point, I would prefer not to change the terminology. 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) > > Changed to: This is a zone transfer over mutually authenticated TLS. 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? > > The IP address of your HNA in our use-case can be any IP address from your prefix. But in any case it defies the purpose of outsourcing, so unless one knows exactly what it does, we do not expect the HNA to appear in the zone. (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) > > changed > (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) > > changed to make sure this is understood. (an ephemeral also commonly designated as high range port) > (another high range port) > > changed to another ephemeral 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. > > YYYY and ZZZZ have been changed. and so DNS notifies are sent over the Control Channel, secured by > TLS. > > mutually authenticated TLS. > > changed > As this AXFR runs over a TCP channel secured by TLS > > mutually authenticated TLS. > > changed > [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) > > changed > 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. > I am expecting more frequent SOA requests. > > The DM SHOULD ignore the Pre-requisite and Additional Data > sections, if > present. > > Why is this not a MUST ? > These fields are potentially left for future use. > > 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. > > deleted > 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 ...." > > changed > 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. > > I do agree. Home networks may also be quite large, and yes the considerations are more for the developers of the protocol which are expected to tweak it to their targeted end users. > 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" ? > > yes. thanks. changed. > This specification defines a mechanism that re-use the [...] > > that re-uses > > changed > An error indicates the MD > > MD -> DM > > changed > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
