Re: [secdir] SecDir review of draft-ietf-dhc-topo-conf-08

[Tomek Mrugalski <[e-mail]>]

Hi Yaron,
Thanks a lot for your review. See my responses inline:

On 03.06.2016 19:04, Yaron Sheffer wrote:
> 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.
>
> This document describes current practices for configuring DHCP in
> complex network scenarios, where the goal is to allow servers to
> configure DHCP clients differently depending on the client's network
> location.
>
> Summary
>
> This is a very extensive document, but the security considerations do
> not do it justice.
>
> Details
>
> The Security Considerations section is essentially empty, saying only
> that drafts that define DHCP options each include their own security
> considerations. However this document references 12 other RFCs (and
> they in fact do have substantial security considerations) so this
> leaves the reader to research the matter on her own.
>
> Moreover, the technology covered spans more than 20 years (15 years,
> counting only Relay Agent Information), and security best practices
> have changed. Old security recommendations may not be today's best
> practices, and some previously recommended mechanisms may have never
> materialized in real-world deployment.
>
> This document is basically a survey of best practices in deploying
> DHCP in complex networks. As such, I would expect the Security
> Considerations section to include:
>
> - Recommendations about which configuration practices are to be
> preferred from a security point of view.
This document essentially explains how the DHCP server determines where
the client is attached. This document does not recommend any practices,
security related or otherwise. Note it's informational, not BCP.
I suppose I could write a text that explains implications of point of
attachment determination for security: especially how fooling this
mechanism could be used as an attack vector. A client tricking the
server to be located in some other location than it really is, could get
options related to some secured network, potentially revealing DNS
servers and other services in that network. Would that be adequate to
address your comment here?
> - Up to date security recommendations in summary form, at least for
> the main use cases covered.
This document does not make any recommendations. If you think about
something like "how to secure your DHCP deployment", that's definitely a
great idea and a topic for separate draft. I'm serious about it. As a
co-chair of DHC, I'd love to see such a document written by someone who
actually runs DHCP in a large network. But in the context of topo-conf,
I don't see how the topic of DHCP security (a much larger problem than
the subnet selection described in topo-conf) could fit in here.
> - An architectural view, at the same level as the rest of the
> document, of how these configurations interact with common security
> practices like firewall-based network separation or NAC.
What you are asking here is impossible to answer, at least in a generic
sense. This document explains one aspect of DHCP server implementations.
It explains what the tool can do for you, not how you are supposed to
use it. I could add some basic recommendations, like "you should not
accept incoming DHCP traffic from outside of your network", but would
that be of any help? Also, speaking of security, there are other drafts
that attempt to improve the situation by introducing strong
cryptography. See draft-ietf-dhc-sedhcpv6-12. Some of your suggestions
could be addressed by that draft. However, you mentioned the time scales
of DHCP. If you are thinking about "how to secure your DHCP deployment"
type of text, this is definitely a material for separate draft. If you
support this idea, I'm more than willing to ask in Berlin if there's
enough manpower to write such a draft. Such a draft would be perfect for
DHC-OPS, but there's no such WG. And there likely never will be, as DHCP
is inherently internal problem.

Also, there's an effort well under way to update DHCPv6
(draft-ietf-dhc-rfc3315bis-04). That may be a good place to address your
questions (at least partially, because it's DHCPv6-only). Note it has
fairly large Section 23 about security considerations and a separate
section about privacy, too. The direct link is
https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-04#section-23.
Does this text addresses your concerns? I would really keep in
rfc3315bis, but if you think it's helpful, I certainly can link it in
topo-conf (or copy over parts of the text if you think it's necessary to
have it in topo-conf).

If you consider privacy part of security problems, then there are
RFC7819 (DHCPv4 privacy analysis), RFC7824 (DHCPv6 privacy analysis) and
RFC7844 (Anonymity profile for DHCPv4 and DHCPv6).

>
> I realize that the document is 3 years old and everyone just wants to
> see it published, but in my opinion it is incomplete in its current form.
There's no rush here. It's been around for a long time, so a month or
two more doesn't matter. My objection here is not based on time, but on
the scope of this document. This document was created to explain one
aspect of DHCP operation. Lots of people don't understand how the DHCP
server knows which options and addresses are selected for which clients.
This draft was created to explain this specific aspect of the protocol.

These are my answers to your comments. I'll do my best to propose
appropriate updated text for security considerations, but please don't
expect general DHCP security recommendations here. Finally, I'm a
software developer guy and I have never ran any network larger network.
My ops experience is limited at best, so I don't feel qualified to give
advice on operational aspects to others.

Tomek