IETF Logo Mail Archive

Re: [dhcwg] Lifetime draft: refresh time should never be more thanIRT_DEFAULT

Joe Quanaim <jdq@lucent.com> Tue, 16 November 2004 15:59 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12697; Tue, 16 Nov 2004 10:59:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU5dl-0007dL-3b; Tue, 16 Nov 2004 10:53:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU5bm-0006vM-4K for dhcwg@megatron.ietf.org; Tue, 16 Nov 2004 10:51:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11680 for <dhcwg@ietf.org>; Tue, 16 Nov 2004 10:51:04 -0500 (EST)
Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU5dx-0000AL-AI for dhcwg@ietf.org; Tue, 16 Nov 2004 10:53:24 -0500
Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAGFouhE019626; Tue, 16 Nov 2004 09:50:57 -0600 (CST)
Received: from kraken by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id iAGFotw08190; Tue, 16 Nov 2004 10:50:55 -0500 (EST)
From: Joe Quanaim <jdq@lucent.com>
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more thanIRT_DEFAULT
Date: Tue, 16 Nov 2004 10:50:55 -0500
User-Agent: KMail/1.7.1
References: <002a01c4c6ac$654323f0$be878182@amer.cisco.com> <D0FDE6C2-32A2-11D9-AA52-000A95D6A618@nominum.com> <20041116132415.GF26517@sverresborg.uninett.no>
In-Reply-To: <20041116132415.GF26517@sverresborg.uninett.no>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200411161050.55774.jdq@lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Cc: Stig Venaas <Stig.Venaas@uninett.no>, Ted Lemon <Ted.Lemon@nominum.com>
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jdq@lucent.com
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>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Stig Venaas wrote:
> I'm not sure we should limit the value to 1 day (default). I'm not
> sure the security problem is that big, and there might be reasons
> for using larger values.

I agree with this assessment.  I do not think there is enough deployment 
experience in dhcpv6 to say that a client MUST cap the value to 1 day.  The 
draft could contain a recommendation saying that this value may be 
appropriate for some networks.

Also, I am not sure a value of 1 day makes a network any more secure.  A rogue 
dhcpv6 server could do much worse than to set the lifetime option to an 
excessive value.  And if a client does not implement the lifetime option 
(which will probably be true for the near term), it is still vulnerable to 
this attack whatever we decide the maximum value should be.

Joe.

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

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