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
Return-Path: <volz@cisco.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 0284521F8762; Thu, 9 Feb 2012 10:58:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 C8HQHmge2rdS; Thu, 9 Feb 2012 10:58:15 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 19E4121F8760; Thu, 9 Feb 2012 10:58:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3079; q=dns/txt; s=iport; t=1328813895; x=1330023495; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=L5FPpEoIzATToO3CnSraeN+s8fF5MeA8sBG/r4YNmpc=; b=kHk3pQfM8bAR3/uM4DmlzaDphK/NmETS7cCTQgH11h3sLLtgDQEzvtTe 3zaHmpz01/oR6Gs6G4brEl59YTi05fhmoOYwqUuQ8HglTefcMxgUE2zqN z7VUrkw7Hj6D8GYu3bTSdVUpy4yQbArWZoMNlww8ovBVNx2tfUQaKW5i8 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAF4WNE+tJXHA/2dsb2JhbABEr1yBB4FyAQEBBBIBHQpLBAIBCBEEAQELBhcBBgEgJQkIAQEEARIIGqIZAZ8ZiDaDIAIFAggPAhIBAgUFCAM3h0ZjBIhIl3eHcg
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="55090987"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 09 Feb 2012 18:58:14 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q19IwEhu000880; Thu, 9 Feb 2012 18:58:14 GMT
Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 12:58:14 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
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>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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
X-OriginalArrivalTime: 09 Feb 2012 18:58:14.0600 (UTC) FILETIME=[C6D8B480:01CCE75C]
X-Mailman-Approved-At: Thu, 09 Feb 2012 10:59:39 -0800
Subject: Re: [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 18:58:16 -0000
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