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

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

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:[e-mail]] On Behalf Of Tomek Mrugalski
Sent: Friday, January 19, 2018 6:31 PM
To: [e-mail]
Subject: Re: [Dhcpv6bis] SecDir review comments on 3315bis-10


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.

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


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.
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.)
BV> The intent was whenever it would normally send those subsequence messages (i.e., at T1 or T2 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".

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

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"?
BV> Yes, looks like something not removed. Should be removed.
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