Subject: [Dhcpv6bis] SecDir review comments on 3315bis-10

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 17 Jan 2018 22:36:03 +0000

Hi:

In case you missed it, attached are the review comments for https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-10.

Below is my take on these. Please review and chime in if you have comments. We likely should develop a consolidated response and also create some "tickets" to track open issues to be resolved.

-          Bernie

13.1: "By default, DHCP server implementations SHOULD NOT generate predictable addresses." The justification for this is not addressed in the security considerations section, while the privacy considerations section might be punting this to RFC 7824, though the only mention I can find in a quick search regards iterative allocation in section 4.3.
BV> Don't think this requires anything further?
20.4.1: RKAP uses HMAC-MD5 for symmetric authentication. As an informational matter for an existing protocol, this is certainly justified, but I don't know how the IETF handles obsolete crypto in standards revisions.
BV> This is what was specified by RFC 3315 and we didn't change it. I don't think we should.
20.4.3: "...the client computes an HMAC-MD5 over the DHCP Reconfigure message [ADD: with zeroes substituted for the HMAC-MD5 field], using the Reconfigure Key received from the server"
BV> While likely a useful clarification, it hasn't caused problems to date.
22. DHCP's security threat model is not clearly stated. For instance, RKAP provides protection against man-on-the-side reconfiguration attacks, but DHCP has no ability by itself to protect against a race between legitimate and rogue DHCP servers: such protection relies on management of multicast groups at layer 2. This is implied by the paragraph on snooping DHCP multicast traffic, but nowhere is it specified normatively that restrictive group management is necessary to eliminate this part of the attack surface. Similarly, it's not clear to me whether a rogue or misconfigured server temporarily in the All_DHCP_Servers or All_DHCP_Relay_Agents_and_Servers multicast group can then hide a client from the official DHCP servers forever by sending it the unicast option, thus maintaining exclusive access to certain messages, notabley Request and Renew. The threat model should be stated clearly in this document, even if the recommended countermeasures are in some other RFC (such as RFC 7610) because they rely on information not in this document.
BV> NEEDS MORE -- More complex response likely needed.
23. Does it make sense to clarify the threat model for privacy? For instance, this protocol doesn't try to defend clients against tracking within a LAN that can observe the DHCP traffic. I can guess what the threat model is, but ISTM that it should be specified explicitly.
BV> How many of those kinds of LANs still exist?

Main points:

11: Should there be stronger 2119-style normative language prohibiting entities from parsing the DUID?
BV> We relaxed it in the bis document (from MUST NOT to SHOULD NOT).
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.
BV> I don't think this is something that 3315bis should get into.
18.2.9: The first and third bullets at the top of the section seem to be in direct contradiction.
BV> Yeah, but it is a MAY saying a client can use a less preferred advertisement if it gives it "more" of what it needs. I think that's OK.
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.
BV> Yeah, but so what. It probably is fairly small in the networks between client and server and does little harm if it happens.
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?
BV> For (1), I would think while client holds the lease and doesn't renegotiated the RKAP. For (2), interesting issue. Easy answer might be to apply modulo 2^64 comparisons but that may make the RDM mostly useless. I'm not even sure how useful the RDM is in terms of replay detection and what clients generally do about it? Regarding (3), it is per server.
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.
BV> Yes, probably useless text because it would also require the clients to "wait" for additional Reply's and release these leases. I'd just remove the text.

Questions/Clarifications:

18: Is a relay with sufficient knowledge permitted to forward a client packet to only the server specified by the matching DUID?
BV> While it could, I don't think we ever want it to do that.

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.)
BV> The intent was whenever it would normally send those subsequence messages (i.e., at T1 or T2 time).
18.3.2: "The server MUST NOT cache its responses." Why?
BV> Because cached responses will not have the proper time values (lifetimes and T1/T2 times) as they are relative.
20.3: "...the replay detection field MUST be set to the value of a strictly monotonically increasing counter." Is this counter per-server?
BV> Yes, for client's it would be with whatever server they are interacting.
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"?
BV> Yes, looks like something not removed. Should be removed.

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.
BV> Probably other instances. Not sure it makes that much difference?
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.)
BV> Yes, we should remove "the".
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").
BV> 5.1 does say "There are additional two message exchanges between the client and server described later in this document." and this is one of those places. It seemed more logical to order the text by how clients do operations?
7.3: Under REPLY, should there be an "or" inserted in the list "Solicit, Request, Renew, Rebind"?
BV> Yes. (Though RFC editor would likely fix too.)
12.1: s/Each IA/Each such IA/. Without "such", this statement taken out of context would mean something very different.
BV> Yes.
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"?
BV> Yes, we could add clarifying text.
13.2: Is "Each IA_TA option contains at lease one temporary address..." supposed to be "at least"?
BV> Yes.
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?
BV> My guess is that layer-2 and layer-3 are well understood. ???

16.3: s/does/do in the third bullet: "contents of the Client Identifier option do not match..." Similarly in 16.6, bullet 2.
BV> Yes.
18.2.4: Remove spurious "server. server."
BV> Yes.
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./
BV> Sure.

Subject: Additional comments
From: Kyle Rose <[email-masked]>
To: "[email-masked]" <[email-masked]>, The IESG <[email-masked]>
Date: Wed, 17 Jan 2018 21:41:29 +0000

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./

Subject: Secdir last call review of draft-ietf-dhc-rfc3315bis-10
From: Kyle Rose <[email-masked]>
To: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 17 Jan 2018 21:39:38 +0000

Let me try sending this to the right .all address.

Reviewer: Kyle Rose
Review result: Ready with issues

I have reviewed 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 primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

13.1: "By default, DHCP server implementations SHOULD NOT generate predictable addresses." The justification for this is not addressed in the security considerations section, while the privacy considerations section might be punting this to RFC 7824, though the only mention I can find in a quick search regards iterative allocation in section 4.3.

20.4.1: RKAP uses HMAC-MD5 for symmetric authentication. As an informational matter for an existing protocol, this is certainly justified, but I don't know how the IETF handles obsolete crypto in standards revisions.

20.4.3: "...the client computes an HMAC-MD5 over the DHCP Reconfigure message [ADD: with zeroes substituted for the HMAC-MD5 field], using the Reconfigure Key received from the server"

22. DHCP's security threat model is not clearly stated. For instance, RKAP provides protection against man-on-the-side reconfiguration attacks, but DHCP has no ability by itself to protect against a race between legitimate and rogue DHCP servers: such protection relies on management of multicast groups at layer 2. This is implied by the paragraph on snooping DHCP multicast traffic, but nowhere is it specified normatively that restrictive group management is necessary to eliminate this part of the attack surface. Similarly, it's not clear to me whether a rogue or misconfigured server temporarily in the All_DHCP_Servers or All_DHCP_Relay_Agents_and_Servers multicast group can then hide a client from the official DHCP servers forever by sending it the unicast option, thus maintaining exclusive access to certain messages, notabley Request and Renew. The threat model should be stated clearly in this document, even if the recommended countermeasures are in some other RFC (such as RFC 7610) because they rely on information not in this document.

23. Does it make sense to clarify the threat model for privacy? For instance, this protocol doesn't try to defend clients against tracking within a LAN that can observe the DHCP traffic. I can guess what the threat model is, but ISTM that it should be specified explicitly.

---

From: Tomek Mrugalski <[email-masked]>
Date: Sat, 20 Jan 2018 00:30:41 +0100

On 17/01/2018 23:36, Bernie Volz (volz) wrote:

> Hi:
>
>  
>
> In case you missed it, attached are the review comments for
> https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-10
> <https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-10>.
>
>  
>
> Below is my take on these. Please review and chime in if you have
> comments. We likely should develop a consolidated response and also
> create some “tickets” to track open issues to be resolved.
>
>  
>
> -          Bernie
>
>  
>
>  
>
> 13.1: "By default, DHCP server implementations SHOULD NOT generate
> predictable addresses." The justification for this is not addressed in
> the security considerations section, while the privacy considerations
> section might be punting this to RFC 7824, though the only mention I
> can find in a quick search regards iterative allocation in section 4.3.
>
> BV> Don’t think this requires anything further?
>
Tomek> I think a discussion explaining that would open a can of worms or
at least a lengthy discussion what kinds of attacks are and are not
possible. We could instead offer to write a separate document that
describes threat models of DHCP.
>
> 20.4.1: RKAP uses HMAC-MD5 for symmetric authentication. As an
> informational matter for an existing protocol, this is certainly
> justified, but I don't know how the IETF handles obsolete crypto in
> standards revisions.
>
> BV> This is what was specified by RFC 3315 and we didn’t change it. I
> don’t think we should.
>
Tomek> I very much hope we won't touch this *again*. We tried multiple
times and failed. We can point to sedhcpv6 (and its previous
iterations). The HMAC-MD5 algorithm can be changed to something more
suited, but it wouldn't address the fundamental issue of reconfigure key
being sent in a plain text.
>
> 20.4.3: "...the client computes an HMAC-MD5 over the DHCP Reconfigure
> message [ADD: with zeroes substituted for the HMAC-MD5 field], using
> the Reconfigure Key received from the server"
>
> BV> While likely a useful clarification, it hasn’t caused problems to
> date.
>
Tomek> Adding clarification is always good. And it also gives a good
impression that we're not trying to wave away all comments.
>
> 22. DHCP's security threat model is not clearly stated. For instance,
> RKAP provides protection against man-on-the-side reconfiguration
> attacks, but DHCP has no ability by itself to protect against a race
> between legitimate and rogue DHCP servers: such protection relies on
> management of multicast groups at layer 2. This is implied by the
> paragraph on snooping DHCP multicast traffic, but nowhere is it
> specified normatively that restrictive group management is necessary
> to eliminate this part of the attack surface. Similarly, it's not
> clear to me whether a rogue or misconfigured server temporarily in the
> All_DHCP_Servers or All_DHCP_Relay_Agents_and_Servers multicast group
> can then hide a client from the official DHCP servers forever by
> sending it the unicast option, thus maintaining exclusive access to
> certain messages, notabley Request and Renew. The threat model should
> be stated clearly in this document, even if the recommended
> countermeasures are in some other RFC (such as RFC 7610) because they
> rely on information not in this document.
>
Tomek> How about proposing to write separate document abotu threat
model, possibly even with recommended mitigation steps?
>
> 23. Does it make sense to clarify the threat model for privacy? For
> instance, this protocol doesn't try to defend clients against tracking
> within a LAN that can observe the DHCP traffic. I can guess what the
> threat model is, but ISTM that it should be specified explicitly.
>
Tomek> I wouldn't want to bundle 7824 and 7844 into this, explaining why
we chose to not bundle everything due to text length being an issue
already. There are references to said RFCs in the text already, but if
this is helpful to address their concern, maybe we could add the
references in couple other places as well?
> BV> We relaxed it in the bis document (from MUST NOT to SHOULD NOT).
Tomek> We can point out the long discussion we had about it and strong
desire from actual operators to be able to parse DUID to gain MAC
address information.
>
> 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.
>
> BV> I don’t think this is something that 3315bis should get into.
>
Tomek> The text proposed is incorrect or at least non-deterministic to
me: "client MUST send a DHCP request for prefix delegation on an
interface with a DHCP server". How would the client know whether there
is a server with the ability to do PD? That's the whole point in sending
the messages to find out.
> BV> Yeah, but it is a MAY saying a client can use a less preferred
> advertisement if it gives it “more” of what it needs. I think that’s OK.
>
Tomek> The text is clear to me, but it's perhaps because we discussed
this many times. Maybe we could add a paragraph explaining that if
client asks for an address and a prefix and gets two responses: first
from a server with preference 20 and only an address and another one
with preference 10 and both address and prefix, the client
implementation may chose the second server.
>
> 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.
>
> BV> Yeah, but so what. It probably is fairly small in the networks
> between client and server and does little harm if it happens.
>
Tomek> I get this as a general comment, not a suggestion to change the
text. We may ask whether the text isn't sufficiently clear ("The
likelihood of delayed and out of order delivery is small enough to be
ignored.  The consequence of the redundant exchange is inefficiency
rather than incorrect operation."). If it isn't, I'd ask for specific
clarification.
>
> 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?
>
> BV> For (1), I would think while client holds the lease and doesn’t
> renegotiated the RKAP. For (2), interesting issue. Easy answer might
> be to apply modulo 2^64 comparisons but that may make the RDM mostly
> useless. I’m not even sure how useful the RDM is in terms of replay
> detection and what clients generally do about it? Regarding (3), it is
> per server.
>
Tomek> 1) I would think it's a runtime parameter, so it is kept until
the client is rebooted or moves to a new location 2) Interesting problem
of academic nature. Do they expect any DHCP deployment to send more than
2^64 packets? It's late, but if I hadn't messed up my calculation, a
server that does 10000 leases/sec would need to run 146 millions of
years before this loops around. We can add some fun with numbers
section, but the honest answer is we don't care.
>
> 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.
>
> BV> Yes, probably useless text because it would also require the
> clients to “wait” for additional Reply’s and release these leases. I’d
> just remove the text.
>
Tomek> +1 for removal. The other mitigation steps (short lifetimes, only
one server) should stay, though.
> 18: Is a relay with sufficient knowledge permitted to forward a client
> packet to only the server specified by the matching DUID?
>
> BV> While it could, I don’t think we ever want it to do that.
>
Tomek>I would say it's up to the relay configuration policy. The spec
assumes relays are dumb forwarders, but we all know that there are
implementations that try to do clever things, like tracking state,
filtering unexpected packets etc. If we overspecify here, we'll make
many relay implementation non-conformant.
>
>
> 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.)
>
Tomek> Should be clarify the text? How about this:

"When possible, the client SHOULD use the best configuration available
(as sent in a REPLY message from the server that was selected) and
continue to request the additional IAs in subsequent RENEW messages sent
to that server".
> BV> Because cached responses will not have the proper time values
> (lifetimes and T1/T2 times) as they are relative.
>
Tomek> And possibly update replay detection value with all it implies.
So the short answer is "it's not worth it".
>
> 20.3: "...the replay detection field MUST be set to the value of a
> strictly monotonically increasing counter." Is this counter per-server?
>
> BV> Yes, for client’s it would be with whatever server they are
> interacting.
>
Tomek> Yes, but this a valid question. I think we should clarify that.
>
> 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"?
>
Tomek> +1.
> Nits:
Agree with Bernie's comments to the nits. Here's my answer to Bernie's
question.
>
> 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").
>
> BV> 5.1 does say “There are additional two message exchanges between
> the client and server described later in this document.” and this is
> one of those places. It seemed more logical to order the text by how
> clients do operations?
>
Tomek> Let's remove the second paragraph in 5.2.

Ok, that's it. I'll get through the genart comments over the weekend.

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 22 Jan 2018 19:01:13 +0000

Hi All:

I haven't yet updated the "draft-ietf-dhc-rfc3315bis-10 IETF Last Call" Google sheet with my and Tomek's comments.

I also figured as the document is on the IESG 1/24 telechat and ballot is open, that we should await the outcome of that - and direction from our AD.

I do believe that many of the nits definitely should be made as they will help the RFC editor. But there really wasn't anything "major".

So, let's wait a bit before moving on anything and we can then figure out next steps - likely it will just be to do more of the minor fixes. If there are a few more complex/contentions things, we can perhaps setup a call to discuss and resolve.

-          Bernie

From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Friday, January 19, 2018 6:31 PM
To: [email-masked]
Subject: Re: [Dhcpv6bis] SecDir review comments on 3315bis-10

-          Bernie

13.1: "By default, DHCP server implementations SHOULD NOT generate predictable addresses." The justification for this is not addressed in the security considerations section, while the privacy considerations section might be punting this to RFC 7824, though the only mention I can find in a quick search regards iterative allocation in section 4.3.
BV> Don't think this requires anything further?
Tomek> I think a discussion explaining that would open a can of worms or at least a lengthy discussion what kinds of attacks are and are not possible. We could instead offer to write a separate document that describes threat models of DHCP.

20.4.1: RKAP uses HMAC-MD5 for symmetric authentication. As an informational matter for an existing protocol, this is certainly justified, but I don't know how the IETF handles obsolete crypto in standards revisions.
BV> This is what was specified by RFC 3315 and we didn't change it. I don't think we should.
Tomek> I very much hope we won't touch this *again*. We tried multiple times and failed. We can point to sedhcpv6 (and its previous iterations). The HMAC-MD5 algorithm can be changed to something more suited, but it wouldn't address the fundamental issue of reconfigure key being sent in a plain text.

20.4.3: "...the client computes an HMAC-MD5 over the DHCP Reconfigure message [ADD: with zeroes substituted for the HMAC-MD5 field], using the Reconfigure Key received from the server"
BV> While likely a useful clarification, it hasn't caused problems to date.
Tomek> Adding clarification is always good. And it also gives a good impression that we're not trying to wave away all comments.

22. DHCP's security threat model is not clearly stated. For instance, RKAP provides protection against man-on-the-side reconfiguration attacks, but DHCP has no ability by itself to protect against a race between legitimate and rogue DHCP servers: such protection relies on management of multicast groups at layer 2. This is implied by the paragraph on snooping DHCP multicast traffic, but nowhere is it specified normatively that restrictive group management is necessary to eliminate this part of the attack surface. Similarly, it's not clear to me whether a rogue or misconfigured server temporarily in the All_DHCP_Servers or All_DHCP_Relay_Agents_and_Servers multicast group can then hide a client from the official DHCP servers forever by sending it the unicast option, thus maintaining exclusive access to certain messages, notabley Request and Renew. The threat model should be stated clearly in this document, even if the recommended countermeasures are in some other RFC (such as RFC 7610) because they rely on information not in this document.
BV> NEEDS MORE -- More complex response likely needed.
Tomek> How about proposing to write separate document abotu threat model, possibly even with recommended mitigation steps?

23. Does it make sense to clarify the threat model for privacy? For instance, this protocol doesn't try to defend clients against tracking within a LAN that can observe the DHCP traffic. I can guess what the threat model is, but ISTM that it should be specified explicitly.
BV> How many of those kinds of LANs still exist?
Tomek> I wouldn't want to bundle 7824 and 7844 into this, explaining why we chose to not bundle everything due to text length being an issue already. There are references to said RFCs in the text already, but if this is helpful to address their concern, maybe we could add the references in couple other places as well?

  Main points:

11: Should there be stronger 2119-style normative language prohibiting entities from parsing the DUID?
BV> We relaxed it in the bis document (from MUST NOT to SHOULD NOT).
Tomek> We can point out the long discussion we had about it and strong desire from actual operators to be able to parse DUID to gain MAC address information.

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.
BV> I don't think this is something that 3315bis should get into.
Tomek> The text proposed is incorrect or at least non-deterministic to me: "client MUST send a DHCP request for prefix delegation on an interface with a DHCP server". How would the client know whether there is a server with the ability to do PD? That's the whole point in sending the messages to find out.

18.2.9: The first and third bullets at the top of the section seem to be in direct contradiction.
BV> Yeah, but it is a MAY saying a client can use a less preferred advertisement if it gives it "more" of what it needs. I think that's OK.
Tomek> The text is clear to me, but it's perhaps because we discussed this many times. Maybe we could add a paragraph explaining that if client asks for an address and a prefix and gets two responses: first from a server with preference 20 and only an address and another one with preference 10 and both address and prefix, the client implementation may chose the second server.

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.
BV> Yeah, but so what. It probably is fairly small in the networks between client and server and does little harm if it happens.
Tomek> I get this as a general comment, not a suggestion to change the text. We may ask whether the text isn't sufficiently clear ("The likelihood of delayed and out of order delivery is small enough to be ignored.  The consequence of the redundant exchange is inefficiency rather than incorrect operation."). If it isn't, I'd ask for specific clarification.

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?
BV> For (1), I would think while client holds the lease and doesn't renegotiated the RKAP. For (2), interesting issue. Easy answer might be to apply modulo 2^64 comparisons but that may make the RDM mostly useless. I'm not even sure how useful the RDM is in terms of replay detection and what clients generally do about it? Regarding (3), it is per server.
Tomek> 1) I would think it's a runtime parameter, so it is kept until the client is rebooted or moves to a new location 2) Interesting problem of academic nature. Do they expect any DHCP deployment to send more than 2^64 packets? It's late, but if I hadn't messed up my calculation, a server that does 10000 leases/sec would need to run 146 millions of years before this loops around. We can add some fun with numbers section, but the honest answer is we don't care.

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.
BV> Yes, probably useless text because it would also require the clients to "wait" for additional Reply's and release these leases. I'd just remove the text.
Tomek> +1 for removal. The other mitigation steps (short lifetimes, only one server) should stay, though.

18: Is a relay with sufficient knowledge permitted to forward a client packet to only the server specified by the matching DUID?
BV> While it could, I don't think we ever want it to do that.
Tomek>I would say it's up to the relay configuration policy. The spec assumes relays are dumb forwarders, but we all know that there are implementations that try to do clever things, like tracking state, filtering unexpected packets etc. If we overspecify here, we'll make many relay implementation non-conformant.

"When possible, the client SHOULD use the best configuration available (as sent in a REPLY message from the server that was selected) and continue to request the additional IAs in subsequent RENEW messages sent to that server".

18.3.2: "The server MUST NOT cache its responses." Why?
BV> Because cached responses will not have the proper time values (lifetimes and T1/T2 times) as they are relative.
Tomek> And possibly update replay detection value with all it implies. So the short answer is "it's not worth it".

Nits:
Agree with Bernie's comments to the nits. Here's my answer to Bernie's question.

Tomek