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

"Bernie Volz (volz)" <volz@cisco.com> Thu, 09 February 2012 18:58 UTC

Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 09 Feb 2012 12:58:14 -0600
Message-ID: <D9B5773329187548A0189ED6503667890AD682D3@XMB-RCD-101.cisco.com>
In-Reply-To: <4F3405D0.7010603@gmail.com>
Thread-Topic: SecDir review of draft-ietf-dhc-dhcpv4-bulk-leasequery-05
Thread-Index: AcznUmlqvI4foktVSJSjlhzJitx4lAACJJWg
References: <4F3405D0.7010603@gmail.com>
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, secdir@ietf.org, draft-ietf-dhc-dhcpv4-bulk-leasequery.all@tools.ietf.org, iesg@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-dhc-dhcpv4-bulk-leasequery-05
Precedence: list

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:yaronf.ietf@gmail.com] 
Sent: Thursday, February 09, 2012 12:44 PM
To: secdir@ietf.org;
draft-ietf-dhc-dhcpv4-bulk-leasequery.all@tools.ietf.org; iesg@ietf.org
Subject: SecDir review of draft-ietf-dhc-dhcpv4-bulk-leasequery-05

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

[secdir] SecDir review of draft-ietf-dhc-dhcpv4-b… Yaron Sheffer
Re: [secdir] SecDir review of draft-ietf-dhc-dhcp… Bernie Volz (volz)
Re: [secdir] SecDir review of draft-ietf-dhc-dhcp… Kim Kinnear
Re: [secdir] SecDir review of draft-ietf-dhc-dhcp… Yaron Sheffer