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

From: Yaron Sheffer <[email-masked]>
Date: Fri, 3 Jun 2016 20:04:21 +0300

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.
- Up to date security recommendations in summary form, at least for the 
main use cases covered.
- 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.

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.

Thanks,
	Yaron

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Jun 2016 18:55:22 +0000

With all due respect, Yaron, I think that your proposal here is surprising and unrealistic.   Enumerating the security tradeoffs you've proposed would be very difficult, and we would almost certainly get it wrong.   Furthermore, there is no pressing need to do this, or if there is, you have not said what it is.

The scope of what you are proposing here would be an entire new document.  If you are interested in working on such a document, I would encourage you to do so, but to increase the scope of work of this document to talk about address allocation with DHCP from a security perspective is not a reasonable ask.

________________________________________
From: Yaron Sheffer [[email-masked]]
Sent: Friday, June 3, 2016 13:04
To: IETF Security Directorate; The IESG; [email-masked]
Subject: SecDir review of draft-ietf-dhc-topo-conf-08

Summary

Details

Thanks,
        Yaron

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 3 Jun 2016 21:05:10 +0200

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

On 03.06.2016 19:04, Yaron Sheffer wrote:
> 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.
>
> 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:
>
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).

> 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

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 5 Jun 2016 00:14:15 +0300

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

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

> the subnet selection described in topo-conf) could fit in here.

I understand why generic DHCP security advice is out of scope here.

> 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
> 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
> topo-conf (or copy over parts of the text if you think it's necessary to

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.

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

> expect general DHCP security recommendations here.

Sounds good, and thanks in advance!

  Finally, I'm a

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 22 Jun 2016 13:38:56 +0200

Hi Yaron,

Thanks again for your review. I came up with a proposed text for the
security considerations text. There's not much left from the original
text, so here's the whole proposed section:

10.  Security Considerations

   This document explains existing practice with respect to the use of
   Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host
   Configuration Protocol Version 6 [RFC3315].  The security
   considerations for these protocols are described in their
   specifications and in related documents that extend these protocols.

   The mechanisms described in this document could possibly be exploited
   by an attacker to misrepresent its point of attachment in the
   network.  This would cause the server to assign addresses, prefixes
   and other configuration options, which can be considered a leak of
   information.  In particular, this could be used a preliminary stage
   of attack, when the DHCP server leaks information about available
   services in networks that attacker does not have access to.

   There are several ways how such an attack can be prevented.  First,
   it seems to be a common practice to filter out DHCP traffic coming in
   from outside of the network and one that is directed to clients
   outside of the network.  Second, the DHCP servers can be configured
   to not respond to traffic that is coming from unknown (i.e. those
   subnets the server is not configured to serve) subnets.  Third, some
   relays provide the ability to reject messages that do not fit
   expected characteristics.  For example CMTS (Cable Modem Termination
   System) acting as a DHCP relay detects if the MAC address specified
   in chaddr in incoming DHCP messages matches the MAC address of the
   cable modem it came from and can alter its behavior accordingly.
   Also, relay agents and servers that are connected to clients directly
   can reject traffic that looks as if it has passed a relay (this could
   indicate the client is attempting to spoof a relay, possibly to
   inject forged relay options).

   There are a number of general DHCP recommendations that should be
   considered in all DHCP deployments.  While not strictly related to
   the mechanisms described in this document, they may be useful in
   certain deployment scenarios.  [RFC7819] and [RFC7824] provide an
   analysis of privacy problems in DHCPv4 and DHCPv6, respectively.  If
   those are of concern, [RFC7844] offers mitigation steps.

   Current DHCPv4 and DHCPv6 standards lack strong cryptographic
   protection.  There is an ongoing effort in DHC working group to
   address this.  [I-D.ietf-dhc-sedhcpv6] attempts to provide mechanism
   for strong authentication and encryption between DHCPv6 clients and
   servers.  [I-D.volz-dhc-relay-server-security] attempts to improve
   security of exchanges between DHCP relay agents and servers.

   Finally, there is an ongoing effort to update DHCPv6 specification,
   that is currently 13 years old.  Sections 23 (Security
   Considerations) and 24 (Privacy Considerations) of
   [I-D.ietf-dhc-rfc3315bis] contain more recent analysis of the
   security and privacy considerations.

If you prefer to see the whole document, the unpublished -09 is
available here:
https://github.com/tomaszmrugalski/ietf-topo-conf/blob/master/draft-ietf-dhc-topo-conf-09.txt

Let me know if the text addresses your comments.

Thanks again for your thorough review.

Tomek

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 29 Jun 2016 23:54:51 +0000

Hi Yaron,
   Any thoughts on this new text? Does this address your concerns?

Thanks
Suresh