Re: [secdir] secdir review of draft-raj-dhc-tftp-addr-option-04
Ralph Droms <rdroms@cisco.com> Tue, 02 December 2008 20:24 UTC
Return-Path: <secdir-bounces@ietf.org>
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38CF928C125; Tue, 2 Dec 2008 12:24:02 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B649928C0CE; Tue, 2 Dec 2008 12:23:59 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ac-PJxXDpUow; Tue, 2 Dec 2008 12:23:58 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2235C3A69BD; Tue, 2 Dec 2008 12:23:58 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,704,1220227200"; d="scan'208";a="29737102"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Dec 2008 20:23:53 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB2KNrVg006741; Tue, 2 Dec 2008 15:23:53 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB2KNrPG004619; Tue, 2 Dec 2008 20:23:53 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 15:23:53 -0500
Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 15:23:52 -0500
Message-Id: <90AC45ED-BF49-46ED-A35A-14E1BF699959@cisco.com>
From: Ralph Droms <rdroms@cisco.com>
To: Samuel Weiler <weiler@watson.org>
In-Reply-To: <alpine.BSF.1.10.0811260255330.4213@fledge.watson.org>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 02 Dec 2008 15:23:51 -0500
References: <alpine.BSF.1.10.0811260255330.4213@fledge.watson.org>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 02 Dec 2008 20:23:52.0934 (UTC) FILETIME=[E4B34060:01C954BB]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7465; t=1228249433; x=1229113433; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20<rdroms@cisco.com> |Subject:=20Re=3A=20secdir=20review=20of=20draft-raj-dhc-tf tp-addr-option-04 |Sender:=20 |To:=20Samuel=20Weiler=20<weiler@watson.org>; bh=YPAgo5jMVnPXLUrfuMjPfkyzaT2QwV/AtJd+q79+dUY=; b=COhQSq23sB2XzvQIYczmDsBki2/QEaFs4FDC6HD6QA4veuta9pq5ypAN++ n0AuVvB71rz27/eayjIr2WaNjRkNr+ceGPI70kvqdtLe+oNk8sLouE2/Ip5/ yxWTJDzvec;
Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
Cc: Richard Johnson <raj@cisco.com>, IETF Discussion <ietf@ietf.org>, secdir@ietf.org, dhc Chairs <dhc-chairs@tools.ietf.org>, IESG IESG <iesg@ietf.org>
Subject: Re: [secdir] secdir review of draft-raj-dhc-tftp-addr-option-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org
Sam - I think most of the issues in your review of draft-raj-dhc-tftp- addr-option-04 can be resolved by reviewing the purposes of RFC 3942 and publishing Informational RFCs describing DHCP option codes. Fundamentally, the reason to publish RFCs under the process described in RFC 3942 is to document existing uses of option codes in the range of option codes reclaimed for assignment to new DHCP options. The concern is to avoid conflicts between new options and those grandfathered ("hijacked") option codes. As such, these RFCs (usually Informational) simply document the already established use of those option codes, so there are only very minimal requirements for demonstrating a need to record the use of the option code, and mandating changes to the established use of the option code is out-of- scope. In the opinion of the dhc WG, this I-D meets the requirements of RFC 3942, which addresses your statement "It's not clear why a distinct code point is needed here" and the suggestions to require DHCP authentication, as well as the pointers to other, similar options are out-of-scope. Responding to some of your specific points: >> At the very least, I suggest mandating the use of DHCP Auth and >> removing the suggestion to use option 66 to enhance security. And, >> in the absence of a more data about how widely used this option is, >> I suggest not publishing this document at all. The consensus of the dhc WG, to which I concur, is to publish the document as Informational. The text in the Security Considerations section about option 66 might be removed. >> It's not clear why a distinct code point is needed here. The >> document >> claims that the "TFTP server name" option (#66) must contain a domain >> name, but I'm pretty sure that real-world devices (e.g. the Cisco >> 7960) happily accept and use v4 address literals in option 66. >> Furthermore, there appear to be other DHCP options that could do the >> trick (e.g. #128, documented in the IANA registry as "TFTP Server IP >> address (for IP Phone software load)"). To reiterate, it's not so much a question of whether a new code point is needed; rather, according to the procedures described in RFC 3942, this document gives a description of an existing use of option code 150. That option code is in use today and, to eliminate any chance of conflict with a new option code in the future, it is entirely appropriate to record the use of the option code in the IANA registry and document its use. >> The document's write-up says is "it is believed that to some extent >> this >> option is in use in some deployments of VoIP devices". That's not a >> very convincing argument that enough devices use this to justify >> invoking the RFC3942 procedure, given that other devices are making >> do >> just fine with existing fields. Richard checked internally at Cisco and got the following response from one of our colleagues: I would say that over 99% of Cisco Unified Communications Manager deployments use Option 150 with a small minority using Option 66. We do support Option 66, but it requires a DNS lookup if specified by name and does not allow for an array of addreses for the purposes of config server redundancy. Any third party phones that support registering with CUCM (e.g. Tandberg, Polycom, Sony, and others) also support using Option 150. Here's more information about uses of option 150 by Cisco customers (current as of 8/19/08): • 95,000+ Cisco Unified Communications customers (all using option 150) • 400+ customers deploying more than 5,000 IP phones • 18M+ IP Phones shipped Also, there are two key differences between the "VoIP Configuration server address" option described in this document and other options: * This option can carry a list of addresses, rather than just a single address. * Cisco's use of the option will ultimately move toward using other protocols such as HTTP instead of TFTP, which is why the name was changed from "TFTP server address" to "VoIP Configuration server address". >> And if we do want to proceed with defining this option: shouldn't it >> also allow for v6 addresses? (The current doc only allows for v4.) As this document describes existing practice and does not define a new option, there is no need to describe a version of the option for DHCPv6 to carry IPv6 addresses. Cisco expects to use a vendor- identifying vendor-specific option for the DHCPv6 version of this option. - Ralph On Nov 26, 2008, at Nov 26, 2008,2:58 AM, Samuel Weiler 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. > > Summary: > > At the very least, I suggest mandating the use of DHCP Auth and > removing the suggestion to use option 66 to enhance security. And, > in the absence of a more data about how widely used this option is, > I suggest not publishing this document at all. > > Details: > > In 2004 RFC3942 defined a procedure for vendors to lay claim to DHCP > option code points that, while previously set aside for "site- > specific" options, had been used by vendors. This document attempts > to claim such a code point. > > It's not clear why a distinct code point is needed here. The document > claims that the "TFTP server name" option (#66) must contain a domain > name, but I'm pretty sure that real-world devices (e.g. the Cisco > 7960) happily accept and use v4 address literals in option 66. > Furthermore, there appear to be other DHCP options that could do the > trick (e.g. #128, documented in the IANA registry as "TFTP Server IP > address (for IP Phone software load)"). > > The document's write-up says "it is believed that to some extent this > option is in use in some deployments of VoIP devices". That's not a > very convincing argument that enough devices use this to justify > invoking the RFC3942 procedure, given that other devices are making do > just fine with existing fields. Do these devices ALSO check option > #66, such that continued use of #150 is really unnecessary? In the > four years since publication of RFC3942, have enough of these devices > been obsoleted (or updated to also use other DHCP option fields) that > this code point is no longer needed? > > And if we do want to proceed with defining this option: shouldn't it > also allow for v6 addresses? (The current doc only allows for v4.) > > The security considerations section cites rogue DHCP servers as attack > vectors, but doesn't do enough to encourage the use of DHCP Auth. > Furthermore, it suggests using the "TFTP server name" option, on the > basis that a client must do a DNS lookup to use the contents, thereby > giving an tiny extra layer of assurance. I'm pretty sure that > real-world devices happily accept v4 literals in option 66, making the > suggestion a poor one. > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir
- [secdir] secdir review of draft-raj-dhc-tftp-addr… Samuel Weiler
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Jeffrey Hutzelman
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Ralph Droms
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… John C Klensin
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Jeffrey Hutzelman
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Samuel Weiler
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Richard Johnson
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Richard Johnson
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Jari Arkko
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Ralph Droms
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Ralph Droms
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Cullen Jennings
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Jeffrey Hutzelman
- Re: [secdir] secdir review of draft-raj-dhc-tftp-… Samuel Weiler