Re: [dhcwg] draft-ietf-dhc-rfc3315bis-10 - FW: Additional comments

["Bernie Volz (volz)" <[e-mail]>]

Oops, didn’t realize that his main comments didn’t make it to the DHC WG mailing list.

See them at https://www.ietf.org/mail-archive/web/secdir/current/msg07810.html.


-       Bernie

From: Bernie Volz (volz)
Sent: Friday, January 19, 2018 3:58 PM
To: [e-mail]
Subject: draft-ietf-dhc-rfc3315bis-10 - FW: Additional comments

Here’s a list of additional comments provided by Kyle Rose when he was reviewing draft-ietf-dhc-rfc3315bis-10.


-          Bernie

From: Kyle Rose [mailto:[e-mail]]
Sent: Wednesday, January 17, 2018 4:41 PM
To: [e-mail]; The IESG <[e-mail]>
Subject: Additional comments

I produced the following comments during my Secdir last call review that are not directly related to Secdir responsibilities.

Main points:

11: Should there be stronger 2119-style normative language prohibiting entities from parsing the DUID?

17.2: "When a client sends a DHCP message for the purpose of prefix delegation, it SHOULD be sent on the interface associated with the upstream router (ISP network)." This seems insufficiently general. ISTM that the client MUST send a DHCP request for prefix delegation on an interface with a DHCP server that has the ability to delegate prefixes for the scope of access required by the clients that will be issued addresses in those subnets. If you have a machine that connects to both the internet and to a private network, as well as hosting LANs of its own, the prefixes you want to assign to those LANs depends on whether you want clients on those networks to access the internet or the private network or both.

18.2.9: The first and third bullets at the top of the section seem to be in direct contradiction.

18.2.11: "The likelihood of delayed and out of order delivery is small enough to be ignored." Transport people may take exception to this statement. It might be sufficient to say something about the assumptions around delayed and out-of-order delivery for UDP on real networks.

20.3: With regard to replay detection, some questions are left unanswered: (1) How long should uniqueness of a replay detection value be enforced by clients? (2) Relatedly, how do you deal with rollover in a monotonically-increasing counter with a fixed width? (3) Can the monotonically-increasing counter value be per-server or must it be shared?

21.14: "...or by having DHCP clients release unused leases using the Release message." How is this actionable? Client behavior is what it is. This should be a normative statement if we want it to be implemented.


Questions/Clarifications:

18: Is a relay with sufficient knowledge permitted to forward a client packet to only the server specified by the matching DUID?

18.2: "When possible, the client SHOULD use the best configuration available and continue to request the additional IAs in subsequent messages [RFC7550]." Took a quick look at 7550. Does this mean to wait until T1/T2 and not keep retrying for those IAs? (This might be implied by the preference for a single state machine, but it might also be interpreted as continuing to request those IAs, resetting T1 and T2 every time.)

18.3.2: "The server MUST NOT cache its responses." Why?

20.3: "...the replay detection field MUST be set to the value of a strictly monotonically increasing counter." Is this counter per-server?

22: What is the security relevance of "Networks configured with delegated prefixes should be configured to preclude intentional or inadvertent inappropriate advertisement of these prefixes"?


Nits:

IAADDR in the glossary is a forward reference to elsewhere in the document. Should a section link be specified here? It's possible there are other instances of this type of thing in the glossary.

Under "singleton option", "once as a the top-level option" is malformed. (The RFC editor will probably pick this stuff up, but no reason not to fix it now.)

5.2: The second paragraph seems to be both redundant (it immediately follows the section describing the interaction) and misplaced (it's under a section addressing specifically "Exchanges Involving Four Messages").

7.3: Under REPLY, should there be an "or" inserted in the list "Solicit, Request, Renew, Rebind"?

12.1: s/Each IA/Each such IA/. Without "such", this statement taken out of context would mean something very different.

12.2: Similarly, "A client must create at least one distinct IA_PD" seems like it should have language limiting the class of clients to those requesting prefix delegation. Should the "must" here then be "MUST"?

13.2: Is "Each IA_TA option contains at lease one temporary address..." supposed to be "at least"?

14: Does there need to be an informational reference for the OSI layer terminology used, or is that just considered common knowledge at this point?

16.3: s/does/do in the third bullet: "contents of the Client Identifier option do not match..." Similarly in 16.6, bullet 2.

18.2.4: Remove spurious "server. server."

18.2.10.1<http://18.2.10.1>: s/Sends a Request message if any of the IAs in the Reply message contains the NoBinding status code to the server that responded./Sends a Request message to the server that responded if any of the IAs in the Reply message contain the NoBinding status code./