IETF Logo Mail Archive

RE: [dhcwg] DHCP_DECLINE question

"Thirumalesh Bhat" <thirub@windows.microsoft.com> Thu, 07 March 2002 06:08 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02540 for <dhcwg-archive@odin.ietf.org>; Thu, 7 Mar 2002 01:08:34 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA20874 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 01:08:36 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16977; Thu, 7 Mar 2002 01:03:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16955 for <dhcwg@optimus.ietf.org>; Thu, 7 Mar 2002 01:03:41 -0500 (EST)
Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02409 for <dhcwg@ietf.org>; Thu, 7 Mar 2002 01:03:38 -0500 (EST)
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 6 Mar 2002 22:03:10 -0800
Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Mar 2002 22:03:10 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 22:03:10 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 22:03:09 -0800
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Wed, 6 Mar 2002 22:00:14 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Subject: RE: [dhcwg] DHCP_DECLINE question
Date: Wed, 06 Mar 2002 22:00:13 -0800
Message-ID: <2E33960095B58E40A4D3345AB9F65EC103C09A39@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [dhcwg] DHCP_DECLINE question
Thread-Index: AcHFm2v1/O2P7KF7RXygAS7iS/eKPAAAMvQ8
From: Thirumalesh Bhat <thirub@windows.microsoft.com>
To: Ted Lemon <Ted.Lemon@nominum.com>, Ralph Droms <rdroms@cisco.com>
Cc: dhcwg@ietf.org
X-OriginalArrivalTime: 07 Mar 2002 06:00:14.0002 (UTC) FILETIME=[59313920:01C1C59D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id BAA16956
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 8bit

If the client loops by sending a DHCP DECLINE, it can cause a denial of service attack on the server as all the addresses in a subnet can be marked as bad. This behavior might happen in a buggy client implementation.
 
A better way to solve this on the server end is to mark the address as bad for a lease lifetime or a multiple of the lease lifetime. Since an address is marked as bad when there is a conflict, it is reasonable to assume that there is a client who already has obtained a lease from the server and is using the address. So when the original client does a renew, the address state can be switched back to lease in use.
 
If the client does a release after getting an ack because it doesnt like some lease parameter and ends up in the init state, the client may loop for ever. As Ted has mentioned, this is a very unlikely real world scenario.
 
thx
 

	-----Original Message----- 
	From: Ted Lemon [mailto:Ted.Lemon@nominum.com] 
	Sent: Wed 3/6/2002 8:41 PM 
	To: Ralph Droms 
	Cc: dhcwg@ietf.org 
	Subject: Re: [dhcwg] DHCP_DECLINE question
	
	

	> In my opinion, a client is within the spec if it sends a DHCPRELEASE
	> immediately after receiving a DHCPACK (for whatever reason).  The
	> DHCPRELEASE will terminate the lease and make the address available for
	> reassignment without causing the server to mark the address as "not to be
	> assigned".
	
	True.
	
	> There is still the open question of whether we want to *recommend* this
	> behavior...
	
	Right.   I'd say we shouldn't, because in all likelihood it's going to
	result in the client looping behavior about which Barr is concerned.    I
	think that we are trying to fix a nonexistant problem here, and the fix
	seems much worse than the problem, particularly since I've never observed
	the problem happening in real life.
	
	
	_______________________________________________
	dhcwg mailing list
	dhcwg@ietf.org
	https://www1.ietf.org/mailman/listinfo/dhcwg
	


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

v2.30.2 | Report a Bug | By Email | System Status