IETF Logo Mail Archive

[dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication)

"Gaurav Halwasia (ghalwasi)" <ghalwasi@cisco.com> Mon, 10 September 2012 11:02 UTC

Return-Path: <ghalwasi@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 A1E6521F84A6 for <dhcwg@ietfa.amsl.com>; Mon, 10 Sep 2012 04:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.766
X-Spam-Level:
X-Spam-Status: No, score=-9.766 tagged_above=-999 required=5 tests=[AWL=0.832, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ehcNUsg+UqIK for <dhcwg@ietfa.amsl.com>; Mon, 10 Sep 2012 04:02:28 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1A04E21F8634 for <dhcwg@ietf.org>; Mon, 10 Sep 2012 04:02:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5495; q=dns/txt; s=iport; t=1347274939; x=1348484539; h=from:to:subject:date:message-id:mime-version; bh=qoIWHw1crYGst73K+L03xzO9AObUwyxXlsX2mTyAEMY=; b=VJQjYYB2JsrsD6O46pRdpXPBTs3R4s4laBcUR6JAWJvRqdbUU6yH8m6A NyPK7QkqLnEXSUppEohq/DxxuMnN5LjNun+7FBmXA97X24mAc+JtvvVxg z1ISTUJveOPjcOYcA8gHJxuQxi5bdjhraKLo3FDf9Bzp+LtzU6jFbTaWZ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EACfHTVCtJXG+/2dsb2JhbABFgku4dYEHgiIBBBIBGl4BKlYmAQQbGodumVqBKJ9ikGlgA6QTgWeCZg
X-IronPort-AV: E=Sophos; i="4.80,396,1344211200"; d="scan'208,217"; a="119965423"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 10 Sep 2012 11:02:18 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8AB2IbP018378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dhcwg@ietf.org>; Mon, 10 Sep 2012 11:02:18 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Mon, 10 Sep 2012 06:02:18 -0500
From: "Gaurav Halwasia (ghalwasi)" <ghalwasi@cisco.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: Reg RFC6704 (Forcerenew Nonce Authentication)
Thread-Index: Ac2PQ7WbKpbVbNLxRMad4YyhUAitEw==
Date: Mon, 10 Sep 2012 11:02:17 +0000
Message-ID: <90903C21C73202418A48BFBE80AEE5EB103AF9@xmb-aln-x06.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.142.105.209]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19174.005
x-tm-as-result: No--30.801100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB103AF9xmbalnx06ciscocom_"
MIME-Version: 1.0
Subject: [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: Mon, 10 Sep 2012 11:02:29 -0000

I was going through RFC6704 (Forcerenew Nonce Authentication) along with original Forcerenew spec RFC3203. If I look at the original spec, I see that we can send Forcerenew to a host who has actually not got it's IPV4 address through DHCP but instead it has got some of the config parameters through DHCP using DHCP INFORM message. So as per original Forcerenew spec, client can send INFORM message as a result of receiving Forcerenew message.

But latest spec on NONCE authentication (RFC6704), I figured out that we are only talking about including FORCERENEW_NONCE_CAPABLE option in DISCOVER/REQUEST messages. We are not actually talking about INFORM callflow.



Is there any deliberate reason why we have not talked about and included INFORM callflow. Well, I don't think this is deliberate, and In my opinion Forcerenew Nonce Authentication should be applicable to the INFORM-ACK call flow as well. Including INFORM-ACK is important. Appreciate if you can share your thoughts on this.



Thanks,

Gaurav

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