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

[Tomek Mrugalski <[e-mail]>]

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