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

"TS Glassey" <tglassey@earthlink.net> Mon, 26 November 2007 16:13 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 1IwgaV-0006Ca-TL; Mon, 26 Nov 2007 11:13:35 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgaU-0006CJ-LM for dhcwg@ietf.org; Mon, 26 Nov 2007 11:13:34 -0500
Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwgaT-0004Tf-VP for dhcwg@ietf.org; Mon, 26 Nov 2007 11:13:34 -0500
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=qUmbrOct+U/15gyl6Hji8dgFjPOH0dr84AKv8IF/Rt7RqPyeIgLKn3SA/K0OJvpO; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [24.23.176.93] (helo=tsg1) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IwgaM-0006zX-Bc; Mon, 26 Nov 2007 11:13:26 -0500
Message-ID: <003d01c83047$468ee400$6401a8c0@tsg1>
From: "TS Glassey" <tglassey@earthlink.net>
To: <anthony.flavin@bt.com>, <mayer@ntp.isc.org>, <mellon@fugue.com>
References: <548EC156325C6340B2E85DF90CAE85860199F3ED@E03MVB3-UKBR.domain1.systemhost.net>
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6
Date: Mon, 26 Nov 2007 07:45:41 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec795a7e727c0be27db5ec7be53d3bb4cb8f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.23.176.93
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, rgayraud@cisco.com
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

----- Original Message ----- 
From: <anthony.flavin@bt.com>
To: <mayer@ntp.isc.org>rg>; <mellon@fugue.com>
Cc: <ntpwg@lists.ntp.org>rg>; <dhcwg@ietf.org>rg>; <rgayraud@cisco.com>
Sent: Monday, November 26, 2007 3:27 AM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6


> Surely an ISP DNS must suffer the same issue. How do DNS implementations
> deal with the same problem given that the "attack" traffic then happens
> far more often.
>
> -----Original Message-----
> From: ntpwg-bounces+anthony.flavin=bt.com@lists.ntp.org
> [mailto:ntpwg-bounces+anthony.flavin=bt.com@lists.ntp.org] On Behalf Of
> Danny Mayer
> Sent: 26 November 2007 04:41
> To: Ted Lemon
> Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org; Richard Gayraud (rgayraud)
> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)
> OptionsforDHCPv6
>
> 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.

Which documents why the IETF is broken. Its run by people who do what they 
want to do rather than by folks who want any and all standards to be vetted 
and brought forth. If this wasnt true there would be a simple and well 
defined vetting process.

>
> 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.

OK...

> Now say Starbucks gets all excited
> about how cheap they are and buys them for all their coffee stores.

yeah... but this is only twenty or thirty thousand nationwide... what's a 
real problem is where someone produces a CABLE MODEM which has hardcoded NTP 
service addresses programmed into the units, and that becomes 75,000 or more 
units per medium sized city.

> 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.

You mean like what happened to PHK, my and other Time Servers last year?

> 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.

NetGear was upright and stepped to the plate unlike the other suppliers, 
especially our friends in SoCal IMHO - 
http://en.wikipedia.org/wiki/NTP_vandalism

>
> 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

Having been a victim of the last flurry and other providers bashing of the 
public time servers let me ask how would they know what the loads on the 
server's are?

They also didnt calculate the DNS overhead into the bigger picture as well, 
so its not just the NTP traffic, but the DNS overhead on the front side of 
the NTP transaction. The real issue here is the California Supreme Court 
ruling on whether IP addresses and Domain Names are protectable as IP's 
which are unique to those users.

>
> 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.

NTP needs a server and server-policy discovery model. DHCP isnt it either, 
nor is DNS really, but they can both be used to prime the pump per se 
though.

>
> Danny
> _______________________________________________
> ntpwg mailing list
> ntpwg@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg
> _______________________________________________
> 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