Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6

"David L. Mills" <mills@udel.edu> Mon, 26 November 2007 21:31 UTC

Return-path: <dhcwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlXh-0007MW-DE; Mon, 26 Nov 2007 16:31:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlXf-0007MH-VQ for dhcwg@ietf.org; Mon, 26 Nov 2007 16:30:59 -0500
Received: from whimsy.udel.edu ([128.4.2.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwlXc-0005sc-Q4 for dhcwg@ietf.org; Mon, 26 Nov 2007 16:30:59 -0500
Received: by whimsy.udel.edu (Postfix, from userid 62) id 04CB916A9; Mon, 26 Nov 2007 21:30:56 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu
X-Spam-Level:
X-Spam-Status: No, score=-2.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1
Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id 7C136169B; Mon, 26 Nov 2007 21:30:52 +0000 (UTC)
Message-ID: <474B3B0A.40608@udel.edu>
Date: Mon, 26 Nov 2007 21:30:50 +0000
From: "David L. Mills" <mills@udel.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: ntpwg@lists.ntp.org, dhcwg@ietf.org
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6
References: <200711260009.lAQ092va059077@drugs.dv.isc.org> <EF06E977-C3D9-4EDF-A126-6CD888BA8F36@fugue.com> <014d01c82fc6$6b1ecd70$6401a8c0@tsg1> <5C093633-A256-4059-AA10-1800F62F522A@fugue.com> <017901c82fd4$9cad3b70$6401a8c0@tsg1> <E0F01D6C-3FB6-4150-9722-32CFF3079327@fugue.com> <018501c82fd7$9ff707e0$6401a8c0@tsg1> <A6BDB3D6-4CDA-4BC1-ADF0-1845E539DD4C@fugue.com> <474A521A.2090905@ntp.org>
In-Reply-To: <474A521A.2090905@ntp.org>
X-Sanitizer: This message has been sanitized!
X-Sanitizer-URL: http://mailtools.anomy.net/
X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc:
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Errors-To: dhcwg-bounces@ietf.org

Danny,

There are two mitigating factors at work here, both mentioned in 
rfc4330. First, if the router hardcodes anything, use a DNS name, not an 
address. Second, any hardcoded name/address must point to a resource 
operated by the manufacturer or another site only with permission of the 
operator.

Dave

Danny Mayer wrote:

> Ted,
>
> Let me try and outline the problem again and please come up with an idea
> which solves this.
>
> 1) The DHCP environment is divided into essentially two groups: Hardware
> like Netgear and Linksys routers and Software like ISC's DHCP Server and
> Nominum's Dynamic Configuration Server. IETF doesn't allow you to create
> a protocol which differentiate between these cases.
>
> The software side of the DHCP implementations are usually run by
> organizations for their internal use and are actively maintained. I have
> few worries about these since it's easy to deal with (relatively
> speaking) errors that the sysadmins make.
>
> The SOHO routers are different since the DHCP servers are built into the
> firmware and shipped in their 10's of thousands to individuals and small
> businesses who want wireless connections and routers but don't want to
> be in the business of configuring and maintaining them.
>
> So let's say Acme Routers ships a router with a builtin DHCP server
> which provides NTP server addresses to provide to the DHCP clients and
> they put just one address in it. Now say Starbucks gets all excited
> about how cheap they are and buys them for all their coffee stores. Now
> you have DHCP providing and amplication DDOS attack as all of those
> people sitting there laptops are all set up with the same NTP server
> address and sending NTP packets to the same NTP server. Note that in the
> UWisc/Netgear incident it was the NTP server built into the router that
> was the problem but it was only one server. Here we are having the
> router distributing the address to other systems which then do the dirty
> work and you'd get 10 times the effect of a Netgear incident. This is
> the problem that I'm trying to solve or rather mitigate.
>
> I refer you to the UWisc/Netgear incident paper that Dave Mills and Dave
> Plonka wrote:
> http://www.eecis.udel.edu/~mills/database/papers/ptti/ptti04a.pdf
> The brief slide version is here:
> http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf
> It also discusses the loads on a number of other servers inclusing NIST
> and USNO
>
> PHK's incident with D-Link is written up here:
> http://news.bbc.co.uk/2/hi/technology/4906138.stm
>
> I await your suggestions on how to prevent the routers becoming
> amplifiers via DHCP to bombarding NTP servers.
>
> Danny
>
> _______________________________________________
> ntpwg mailing list
> ntpwg@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg