[secdir] SecDir review of draft-ietf-dhc-dhcpv4-bulk-leasequery-05
Yaron Sheffer <yaronf.ietf@gmail.com> Thu, 09 February 2012 17:43 UTC
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE6121E8021; Thu, 9 Feb 2012 09:43:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.836
X-Spam-Level:
X-Spam-Status: No, score=-102.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_BEZEQINT_B=0.763, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYAJH66EcHo8; Thu, 9 Feb 2012 09:43:47 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5642A21E8014; Thu, 9 Feb 2012 09:43:47 -0800 (PST)
Received: by werm10 with SMTP id m10so1934078wer.31 for <multiple recipients>; Thu, 09 Feb 2012 09:43:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=8edL5GMjNCHrrFOOjOC4pnPsE4OuJwZ+cX8uq61bGEk=; b=RGRZMGOivO6u37kU1Rut3VM1MoE1fESrGfIoD9bAB3Uzbs6AQb9olWA4t2uQUJrlmz na44dQ8m4kwAQ7vNScTiMcFftrnyijZGNRo7b8lVYKO9qrb8dWk/dM6KPw5wgJ91JQMH 0xUP/CmJDI/y/zoNykWlt/TTB4qAa5VSVcwuk=
Received: by 10.180.104.4 with SMTP id ga4mr34404263wib.17.1328809426587; Thu, 09 Feb 2012 09:43:46 -0800 (PST)
Received: from [192.168.3.141] (bzq-218-164-247.red.bezeqint.net. [81.218.164.247]) by mx.google.com with ESMTPS id q7sm8135625wix.5.2012.02.09.09.43.45 (version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 09:43:45 -0800 (PST)
Message-ID: <4F3405D0.7010603@gmail.com>
Date: Thu, 09 Feb 2012 19:43:44 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: secdir@ietf.org, draft-ietf-dhc-dhcpv4-bulk-leasequery.all@tools.ietf.org, iesg@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [secdir] SecDir review of draft-ietf-dhc-dhcpv4-bulk-leasequery-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Feb 2012 17:43:48 -0000
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