Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication)

"Bernie Volz (volz)" <volz@cisco.com> Wed, 12 September 2012 03:01 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8526A21F8539 for <dhcwg@ietfa.amsl.com>; Tue, 11 Sep 2012 20:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.199
X-Spam-Level:
X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpTDcVvHw8Rt for <dhcwg@ietfa.amsl.com>; Tue, 11 Sep 2012 20:01:23 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BD89521F8534 for <dhcwg@ietf.org>; Tue, 11 Sep 2012 20:01:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2217; q=dns/txt; s=iport; t=1347418883; x=1348628483; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5pgIvDDWKS1pXOqqOAKugeNZ8op/DAEz0rdUYVhaRDo=; b=FLeOSgSveDoyhd56fwYzMnKaxrwzJihkUe5FjlLLZQ/NEJ+ZZXVlboZU nxTIfVVK72V9Qk4G6JwNGn/dPCNUFjD1bpU47PHa4LcTD6Z8Ibd6VLMsB OOufnnnL+Nj0sFjAVVTrXMthMWeJwm03W5wIYN9D9NAao8gd9Euh5LGiH w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAPj5T1CtJV2c/2dsb2JhbABFu1eBB4IgAQEBBAEBAQ8BWwsSAQgYVQslAgQBDQUih2sLm0igUQSLEBSGLgOVX442gWmCZoFaPQ
X-IronPort-AV: E=Sophos;i="4.80,407,1344211200"; d="scan'208";a="120637430"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 12 Sep 2012 03:01:23 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8C31NHk009896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 03:01:23 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Tue, 11 Sep 2012 22:01:22 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Ted Lemon <Ted.Lemon@nominum.com>, "Gaurav Halwasia (ghalwasi)" <ghalwasi@cisco.com>
Thread-Topic: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication)
Thread-Index: AQHNkE8ckuiEXtYUDkaNnWZTSjI1wpeF7kOA////THCAAGj/AP//v1kA
Date: Wed, 12 Sep 2012 03:01:22 +0000
Message-ID: <CC7572B0.223C%volz@cisco.com>
In-Reply-To: <F8B51038-A94A-4D9B-9F91-8542D0D09127@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.86.250.25]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.000
x-tm-as-result: No--47.304500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <8B1260EE301FCD4296D02BBBA078F6B9@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Sep 2012 03:01:24 -0000

Ted Š I think you are spot on. We really have to prioritize and handle the
major issues and also focus on the future - IPv6 and getting there.
Marginal extensions to IPv4 should be very low priority (or even better
dropped).

- Bernie

On 9/11/12 10:52 PM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:

>On Sep 11, 2012, at 9:45 PM, "Gaurav Halwasia (ghalwasi)"
><ghalwasi@cisco.com>
> wrote:
>> I am talking about a deployment where we do create *session* database
>>for hosts either based upon DHCP packet (Discover) or the normal IP
>>packet in case few of the hosts has not done DHCP but instead has just
>>DONE DHCP INFORM to get the config parameters. So in this kind of
>>deployment we do anyways maintain the session(or binding in terms of
>>DHCP) database on the box. Having said that I don't think storing client
>>information is a problem (at least in this deployment). The only extra
>>thing which we would need to store is a 'nonce'.
>
>This is a heavy burden for the working group to take on for a small
>deployment.   Can you go into some detail about why this is the right way
>to solve the problem, and what bad things would happen if you didn't have
>FORCERENEW?
>
>I'm sorry to be stubborn about this, but you're talking about a DHCPv4
>protocol extension, and as you know from another draft that just went to
>the IESG, bandwidth is limited for the DHC working group‹we've had
>presentation marathons at the last two IETFs, and I've had to chivvy
>presenters mercilessly just to avoid running over the generous time slots
>we've been given.   I feel really bad about doing that, and so I'm going
>to push back on proposals like this if I don't have a clear sense of
>their broad utility.   I say this sort of wearing my working group
>co-chair hat and sort of wearing my working group participant hat‹as a
>participant, I don't see the broad utility in this proposal, and as a
>chair I see a lot of work in my future.   So please, give us a clear
>sales pitch for why we should feel good about taking on this work.
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg