Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure)

Ted Lemon <Ted.Lemon@nominum.com> Fri, 24 August 2012 13:44 UTC

Return-Path: <Ted.Lemon@nominum.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 681AC21F8686 for <dhcwg@ietfa.amsl.com>; Fri, 24 Aug 2012 06:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.558
X-Spam-Level:
X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 vKRmlneLkcKM for <dhcwg@ietfa.amsl.com>; Fri, 24 Aug 2012 06:44:05 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9216221F865B for <dhcwg@ietf.org>; Fri, 24 Aug 2012 06:44:05 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUDeFJUwHL2tPYPhraIeTkr9qZOh9rHG9@postini.com; Fri, 24 Aug 2012 06:44:05 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 85FF91B82B9 for <dhcwg@ietf.org>; Fri, 24 Aug 2012 06:44:04 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7350919005C; Fri, 24 Aug 2012 06:44:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 24 Aug 2012 06:43:58 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Thread-Topic: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure)
Thread-Index: Ac2B6QUqwYS2/P4sSIahdPn5lTXDIwABPhGAABLMSoA=
Date: Fri, 24 Aug 2012 13:43:58 +0000
Message-ID: <264AF650-EB56-4C12-9A1D-F1A92FEACB39@nominum.com>
References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_264AF650EB564C129A1DF1A92FEACB39nominumcom_"
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure)
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: Fri, 24 Aug 2012 13:44:07 -0000

On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:
Comments and suggestions are more than welcome.

In section 2, you propose that the reconfigure-request include an RSOO, but this is actually not necessary; what will happen is that the RECONFIGURE-REQUEST will trigger a RECONFIGURE, the client will then send a RENEW, the relay will piggyback an RSOO on the RENEW containing, e.g., the new AFTR_NAME option, and the DHCP server will send a REPLY containing the AFTR_NAME option.   So there's no need to include that in the RECONFIGURE-REQUEST.   This is a minor point--it would certainly do no _harm_ to include the AFTR_NAME option in the RSOO on the RECONFIGURE-REQUEST.

So of course if you make this change, you'd have to fix up section 3.2.

I would also change this, in section 3.2:


If the server is configured to reject RECONFIGURE-REQUEST, any received RECONFIGURE-REQUEST is silently dropped.

To this:


If the server is configured to reject RECONFIGURE-REQUEST, the server MUST silently discard any RECONFIGURE-REQUEST it receives.

It might be good to consistently say "silently discard" instead of "discard" in that section.

Section 3.3 also mentions sending the RSOO, and, if you accept my argument above, should not.

In addition to the issues discussed in the Security Considerations section of RFC5007, you might also want to add this (possibly to section 3.2, not to the Security Considerations section):

Because this message provides a mechanism for triggering the DHCP Reconfigure message, and the DHCP Reconfigure message can be used by an attacker to control the timing of a DHCP renewal, the DHCP server must have some mechanism for determining that the relay agent is a trusted entity.   RECONFIGURE-REQUEST messages originating from unknown relay agents MUST be silently dropped.

Aside from this, the document looks good, and seems useful.   Are you proposing that the working group should adopt this work?