Subject: [secdir] SecDir review of draft-ietf-dhc-dhcpv4-bulk-leasequery-05

From: Yaron Sheffer <[email-masked]>
Date: Thu, 09 Feb 2012 19:43:44 +0200

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.

The document defines a protocol extension that allows infrastructure 
components in DSL/cable networks to query a master DHCP server for its 
static and/or dynamic bindings, to allow them to quickly recovery after 
reboot.

Summary

In my opinion, a major security issue is not covered sufficiently.

Details

I have not reviewed the protocol itself in depth. However I believe that 
it suffers from the "recursive security considerations" syndrome, where 
the current draft depends on RFC 4388 (6 years old) for its security, 
which in turn refers to RFC 3118 (11 years old) for parts of its 
security. IMHO the relevant threats for a bulk DHCP query are very 
different from those that RFC 3118 considered for generic DHCP.

I worry most about the privacy implications: if I am a subscriber in 
Smalltown, pop. 10,000, I may be sharing a single DHCP server with the 
entire population. If any subscriber can issue a bulk query for the 
whole town once every hour, and thereby map any IP address to a MAC 
address, this has a serious effect on subscribers' privacy.

This is what the current draft says about access control:

Servers MAY restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY 
messages to certain requestors.  Connections not from permitted 
requestors SHOULD be closed immediately, to avoid server connection 
resource exhaustion.  Servers MAY restrict some requestors to certain 
query types.  Servers MAY reply to queries that are not permitted with 
the DHCPLEASEQUERYDONE message with a status-code option status of 
NotAllowed, or MAY simply close the connection.

This IMHO is way too weak, specifically the first MAY. The Security 
Considerations refer to RFC 4388 for "restriction to trusted 
requestors", but I couldn't find any relevant language there either, 
other than a reference to RFC 3118.

Thanks,
     Yaron

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 9 Feb 2012 12:58:14 -0600

Yaron:

Actually, the text used here was used "recently" for RFC 5460 (and also
RFC 5007) - the DHCPv6 Leasequery.

As this is the only use of TCP for DHCPv4, it really should be strongly
recommended that firewalls block any 'external' (from
subscribers/Internet) TCP traffic to the bulk leasequery port.  This
should be much easier to secure than UDP based traffic - as the 4388
leasequery and normal DHCP traffic both happen over the same UDP port
and it is hard to filter 'all' traffic as clients do need to communicate
directly with the DHCP server.

- Bernie

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Thursday, February 09, 2012 12:44 PM
To: [email-masked];
[email-masked]; [email-masked]
Subject: SecDir review of draft-ietf-dhc-dhcpv4-bulk-leasequery-05

Summary

Details

Thanks,
     Yaron

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 16 Feb 2012 10:40:41 -0500

Yaron,

On Feb 9, 2012, at 12:43 PM, 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.
> 
> The document defines a protocol extension that allows infrastructure components in DSL/cable networks to query a master DHCP server for its static and/or dynamic bindings, to allow them to quickly recovery after reboot.
> 
> Summary
> 
> I have not reviewed the protocol itself in depth. However I believe that it suffers from the "recursive security considerations" syndrome, where the current draft depends on RFC 4388 (6 years old) for its security, which in turn refers to RFC 3118 (11 years old) for parts of its security. IMHO the relevant threats for a bulk DHCP query are very different from those that RFC 3118 considered for generic DHCP.

	For what it is worth, the security section for this draft
	is taken essentially verbatim from RFC 5460, DHCPv6 Bulk
	Leasequery.  But I assume that we must be raising the bar
	here, since that was 3 years ago.
> 
> I worry most about the privacy implications: if I am a subscriber in Smalltown, pop. 10,000, I may be sharing a single DHCP server with the entire population. If any subscriber can issue a bulk query for the whole town once every hour, and thereby map any IP address to a MAC address, this has a serious effect on subscribers' privacy.

> Servers MAY restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY messages to certain requestors.  Connections not from permitted requestors SHOULD be closed immediately, to avoid server connection resource exhaustion.  Servers MAY restrict some requestors to certain query types.  Servers MAY reply to queries that are not permitted with the DHCPLEASEQUERYDONE message with a status-code option status of NotAllowed, or MAY simply close the connection.
> 
> This IMHO is way too weak, specifically the first MAY. The Security Considerations refer to RFC 4388 for "restriction to trusted requestors", but I couldn't find any relevant language there either, other than a reference to RFC 3118.

	The theory behind all of this is that you should not
	allow TCP connections to the DHCPv4 ports from any
	devices or programs that are not part of your
	infrastructure.

	In almost all cases, the actual DHCP server isn't
	involved in the configuration of these restrictions, but
	rather these restrictions are imposed by network elements
	at a deeper level of the network than the DHCPv4 server
	(which is, after all, most usually an application running
	on a standard operating system).

	Of course, that doesn't mean that we shouldn't give
	people guidance as to what is important to restrict and
	what isn't.

	It seems a bit ... unenforceable .. to say that DHCPv4
	servers which implement the Bulk Leasequery capability
	MUST be installed in environments where it is possible to
	configure access to the Bulk Leasequery capability only
	to trusted network components.d  But I'll give it a
	try, below.

	I can certainly uplift the paragraph above on access
	control to SHOULD (and replicate it in the Security
	section), like this:
> 
>    Servers SHOULD restrict Bulk Leasequery connections and
>    DHCPBULKLEASEQUERY messages to certain requestors, either
>    through explicit configuration of the Server itself or by
>    employing external network elements to provide such
>    restrictions.  In particular, the typical DHCPv4 client SHOULD
>    NOT be allowed to receive a response to a Bulk Leasequery
>    request, and some technique MUST exist to allow prevention of
>    such access in any environment where Bulk Leasequery is
>    deployed.
> 
>    Connections not from permitted requestors SHOULD be
>    closed immediately, to avoid server connection resource
>    exhaustion or alternatively, simply not be allowed to reach
>    the server at all.  Servers SHOULD have the capability to
>    restrict certain requestors to certain query types.  Servers
>    MAY reply to queries that are not permitted with the
>    DHCPLEASEQUERYDONE message with a status-code option status
>    of NotAllowed, or MAY simply close the connection.

	Would this change sufficiently mitigate your concerns
	regarding this draft?

	Regards -- Kim

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 16 Feb 2012 17:49:52 +0200

Hi Kim,

thanks for the new text. Yes, it does mitigate my concerns.

Regards,
	Yaron