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

Brian Utterback <Brian.Utterback@Sun.COM> Sun, 25 November 2007 21:24 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 1IwOxX-0007uW-0y; Sun, 25 Nov 2007 16:24:11 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwOxV-0007uQ-2p for dhcwg@ietf.org; Sun, 25 Nov 2007 16:24:09 -0500
Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwOxU-0002fK-FF for dhcwg@ietf.org; Sun, 25 Nov 2007 16:24:09 -0500
Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAPLO7ba001355 for <dhcwg@ietf.org>; Sun, 25 Nov 2007 21:24:07 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS200801ZCRWC00@mail-amer.sun.com> (original mail from Brian.Utterback@Sun.COM) for dhcwg@ietf.org; Sun, 25 Nov 2007 14:24:07 -0700 (MST)
Received: from [192.168.1.5] ([71.168.64.220]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS2008IZZG6HQA0@mail-amer.sun.com>; Sun, 25 Nov 2007 14:24:07 -0700 (MST)
Date: Sun, 25 Nov 2007 16:24:06 -0500
From: Brian Utterback <Brian.Utterback@Sun.COM>
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor DHCPv6
In-reply-to: <00af01c82fa5$8a9acfd0$6401a8c0@tsg1>
To: TS Glassey <tglassey@earthlink.net>
Message-id: <4749E7F6.8010709@sun.com>
MIME-version: 1.0
Content-type: text/plain; format="flowed"; charset="ISO-8859-1"
Content-transfer-encoding: 7bit
References: <20071121052610.DD3EF39E3F@mail1.ntp.org> <4748DAB1.2030506@ntp.org> <6EDC6595-CD66-490F-90FD-A730E4BF3360@fugue.com> <4748F4C4.1090407@ntp.org> <47496F73.8040206@sun.com> <000701c82f6e$03795350$6401a8c0@tsg1> <4749D28D.8090505@sun.com> <00af01c82fa5$8a9acfd0$6401a8c0@tsg1>
User-Agent: Thunderbird 2.0.0.6 (X11/20071009)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: ntpwg@lists.ntp.org, Ted Lemon <mellon@fugue.com>, "Richard Gayraud (rgayraud)" <rgayraud@cisco.com>, dhcwg@ietf.org
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

TS Glassey wrote:
>   
>> But we are not talking about anything to due with the security model, 
>> assurance or reliability. The
>> question at hand is how to avoid abusive spamming of servers by persistent 
>> and pervasive clients.
>>     
>
> OK but that sounds like Integrity of Opertions insurance to me, si?
>
> Isnt the issue is how to authenticate any control processes since without 
> this I can slam the server's with bad requests to make it unavailable to the 
> legit users.
>
> ?????
>
> Todd
>
>   
Sort of. We aren't talking about any protection from malicious clients, 
we are dealing with the inadvertent
slamming of a server due to long term up time of multiple clients that 
use the same IP address forever and
ever.  If a client is served an IP address at start up time, it has no 
choice but to use that address for the
entire time it is up and running. If a particular DHCP server serves the 
same IP to all of its clients, the
problem is multiplied. If the DHCP happens to be an embedded client, 
with the server IP hard-coded and
this embedded client is deployed to multiple thousands of home 
appliances, then we have the Netgear/Wisc
fiasco again.

Is this scenario likely enough to be worth making major modifications to 
the way DHCP does things?
This is what seems unlikely to Ted and I. Rather than jump through hoops 
at the client protocol
level, a requirement that the IP served not be hard coded at the server 
might be enough. A compromise
on Danny's compromise might be that the addresses must either be 
site-local, or determined dynamically
by the server via DNS lookup.

Brian Utterback


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