[secdir] Security directorate review of draft-ietf-homenet-naming-architecture-dhc-options-21

[Hilarie Orman <[e-mail]>]

            	 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