Security review of DHCPv6 Options for Home Network Naming Authority draft-ietf-homenet-naming-architecture-dhc-options-21 Do not be alarmed. I generated this review of this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This seems like a simple protocol for communicating a few parameters between a home network and an ISP. As a result of the exchange, the home network can configure its DNS data with the IPv6 data from its ISP and communicate it to outsourcing data managers (forward and reverse). These managers might be provided by the ISP or by a third-party chosen by the home network. Opinion: Not Ready "7. Security Considerations The security considerations in [RFC8415] are to be considered. The use of DHCPv6 options provides a similar level of trust as the one used to provide the IP prefix." I can almost believe this is true, but I would like some additional discussion. First, the "use of the options" does not "provide a level of trust". One might say that the trust relationships are the same because the home network must rely on the IP prefix to configure its DNS data and no additional security relevant data is communicated? I'm not sure, but I am sure that "Security Considerations" need more ... consideration. The section in Appendix B that speaks of the DHCPv6 server presenting credentials to the DM and RDM should be amplified, as well. The grammar in the document is rough, and as a result I found it very difficult to read. I wish there were an IETF "grammar ready" review before passing a document on the content reviewers. My notes below are mostly meant to clarify content and they address only a few of the subject/verb mismatches. --------- In section 2 Introduction: Confusing sentence: "This document describes DHCPv6 options that enable an ISP to provide the necessary parameters to the HNA, to proceed. More specifically," Possible rewrite: An ISP can use the DHCPv6 options described in this document to communicate parameters to the HNA. Specifically, ... --------- In addition, ISPs often identify the line of the home network with a name. Such name is used for their internal network management operations and is not a name the home network owner has registered to. ISPs may leverage such infrastructure ... I think this verbiage is unneccesary and confusing. What is a "line" and why do we need to know that it has a name that can't be used? --------- and provide the homenet with a specific domain name designated as per [I-D.ietf-homenet-front-end-naming-delegation] a Homenet Registered Domain. (should be "Registered Homenet Domain") --------- This document does not ignore scenarios where the DHCPv6 server does not have privileged relations with the DM or RDM. These cases are discussed in Appendix A. Possible rewrite: Appendix A of this document addresses scenarios where the DHCPv6 server does not have privileged relations with the DM or RDM. --------- The "Procedure Overview" has a 3 step procedure with steps numbered "1, 2, 1". The third step states: The HNA may complement the configurations with additional parameters via means not yet defined. I suppose that is always the case, but why "specify" something so vague, and might these unknown things relevant to security? -------- In "4.2. Forward Distribution Manager Option" there is a badly garbled sentence that I cannot unwind. Then the FQDN can reasonably be seen as a more stable identifier as well as a pointer to additional information than the IP addresses may be useful to in the future to establish the communication between the HNA and the DM. This sentence "It is worth noticing that the Supported Transport field does not enable to specify a port and the used port is defined by standard." might be better stated as "Note that the Supported Transport field specifies a protocol but there is no option for defining a port number. The port number is defined by other RFCs. In the case of DNS over TLS [RFC7858], the port is defined by [RFC7858] to be 853." --------- 5.1. DHCPv6 Server Behavior This paragraph is particularly confusing: In particular, when configured the DHCPv6 server sends the Registered Homenet Domain Option, Distribution Manager Option, the Reverse Distribution Manager Option when requested by the DHCPv6 client by including necessary option codes in its ORO. Possible rewrite: Upon receiving a request from a DHCPv6 client that includes the necessary option codes in its ORO, a configured DHCPv6 server will send the Registered Homenet Domain Option, Distribution Manager Option, and the Reverse Distribution Manager Option. ------------ Appendix A "This section details various scenarios and discuss their impact on ^ discusses the end user. This section is not normative and limits the description of a limited scope of scenarios that are assumed to be representative." How does it "limit the description"? Confusing. It is also confusing that Appendix A does not have any discussion of scenarios. Maybe Appendix A is an introduction to Appendix B? I've never seen a document organized in this way. ------------ "The end user subscribes to the ISP (foo) ..." Previously "foo" was used as an option. Too fooey. How about "the ISP (exampleISP)"? ------------ "In this scenario, the DHCPv6 server, DM and RDM are managed by the ISP so the DHCPv6 server and as such can provide authentication credentials of the HNA to enable secure authenticated transaction with the DM and the Reverse DM." In this scenario, the DHCPv6 server, DM and RDM are managed by the ISP. The DHCPv6 server can provide the authentication credentials of the HNA to the DM and Reverse DM to enable secure authenticated transactions. Authenticated transactions between the HNA and the DM (or RDM)? Is the HNA a party to this authentication? How? ------------ B.1. Third Party Registered Homenet Domain This section still considers the ISP ^ assumes? manages the home network and still provides foo.example as a Registered Homenet Domain. ------------ B.2. Third Party DNS Infrastructure "Again, this configuration update is done once-for- ever." ??? Again? What was the first time? "Forever" ... really? ------------ With the configuration described in Appendix B.1, the HNA is expect ^^ expected to be able to handle multiple Homenet Registered Domain, --------- The drawback of this scenario may be that the end user still rely on the ISP naming infrastructure. Note that the ^^ relies only case this may be inconvenient is when the DNS servers provided ^^ where by the ISPs results in high latency. ^^ result --------- Hilarie