Last Call Review of draft-ietf-dhc-dhcpv4-bulk-leasequery-

Request Review of draft-ietf-dhc-dhcpv4-bulk-leasequery
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-02-14
Requested 2012-01-27
Authors D.T.V. Rao, Pavan Kurapati, Bernie Volz, Kim Kinnear, Mark Stapp, Bharat Joshi, Neil Russell
Draft last updated 2012-02-15
Completed reviews Secdir Last Call review of -?? by Yaron Sheffer
Tsvdir Last Call review of -?? by Joseph Touch
Assignment Reviewer Yaron Sheffer
State Completed
Review review-ietf-dhc-dhcpv4-bulk-leasequery-secdir-lc-sheffer-2012-02-15
Review completed: 2012-02-15


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 



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


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.