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

[Yaron Sheffer <[e-mail]>]

Hi Tomek,

Thank you for your thorough response.

While I may have read this draft as more than it is intended to be, it 
seems to me that security is an important consideration in engineering 
the kind of networks described here, and in selecting which DHCP server 
should respond to requests from which link and with what information.

Specifically I have in mind complex networks where links have different 
sensitivity levels (e.g. guest vs. generic access vs. data center) and 
where people employ the mechanisms described in this document with the 
goal of keeping the networks separate even in the face of malicious actors.

So let us try to understand what security advice is appropriate in this 
context.

Please see further comments below.

Thanks,
	Yaron

On 03/06/16 22:05, Tomek Mrugalski wrote:
> 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?

That would be useful. I wonder if there are additional security 
considerations, such as: can a fake relay obtain any sensitive 
information by looking at requests?

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

I understand why generic DHCP security advice is out of scope 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.

I am a bit skeptical of real-world deployment of cryptographic solutions 
at this level of the stack, but let's wait an see. However, can the 
security of sedhcpv6 be affected if there are multiple DHCP 
servers/relays in a complex network and a client talks to the wrong 
server/relay?

  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?

The text is lengthy and very interesting, but does not seem to discuss 
any issues related to multiple DHCP servers and relays sharing the same 
physical network.

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

I am not proposing to copy text between documents. But a link to a few 
specific documents where the security considerations are best clarified 
(and are most relevant to the kind of networks discussed here) would be 
appreciated.

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

Again, are there privacy considerations that are specifically pertinent 
to the type of connectivity discussed in this document?

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

Sounds good, and thanks in advance!

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