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

["Gaurav Halwasia (ghalwasi)" <[e-mail]>]

Hi Med,

Thanks for taking care of my suggestions and comments. I am fine with these changes.

Thanks,
Gaurav
From: [e-mail] [mailto:[e-mail]]
Sent: Monday, August 27, 2012 11:08 AM
To: Gaurav Halwasia (ghalwasi); Ted Lemon
Cc: [e-mail]
Subject: RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure)

Dear Gaurav,

Please see inline.

Cheers,
Med

________________________________
De : Gaurav Halwasia (ghalwasi) [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>
Envoyé : dimanche 26 août 2012 16:48
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Ted Lemon
Cc : [e-mail]<mailto:[e-mail]>
Objet : RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure)
Specifying the correct reference to RFC.


Hi Med,



I have few comments on this draft.



1.) I think just restricting this proposed capability to RSOO is not a good idea. I can think of use cases in which relay agent might want to trigger RECONFIGURE in non-RSOO scenarios as well. (Infact I am working on a I.D which is work in progress which proposes similar capability in DHCPv4). Probably you can refer RSOO as the use case for this draft instead of restricting this for only RSOO scenario. This is also inline with the comments from Ted on the other email thread on not including  RSOO in the RECONFIG-REQUEST message.
[Med] In my local copy, including RSOO is now optional: "an RA MAY include RSOO option". I also added a sentence to say this procedure can be applied in non-RSO scenarios. Would you be fine with these changes?



2.) I also agree comment from Andre Kostur wherein Relay Agent MAY include OPTION_RECONF_MSG option in the RECONFIGURE-REQUEST message to indicate what do you want the client to send after receiving RECONFIGURE message. i.e Renew/Info-Request. Infact there is a RFC which added capability to trigger REBIND after receiving RECONFIGURE message. (Rebind Capability in DHCPv6 Reconfigure Messages - RFC 6644). So it would certainly be useful to include OPTION_RECONF_MSG on this message.
[Med]Agreed. I updated my local copy accordingly.

Thanks,
Gaurav


From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Friday, August 24, 2012 8:10 PM
To: Ted Lemon
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure)

Dear Ted,

Thank your for the review.

Please see inline.

Cheers,
Med

________________________________
De : Ted Lemon [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>
Envoyé : vendredi 24 août 2012 15:44
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [e-mail]<mailto:[e-mail]>
Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure)
On Aug 24, 2012, at 7:49 AM, [e-mail]<mailto:[e-mail]> 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.
[Med] That's make sense too. I changed "MUST" to "MAY" in Section 3.3: the point is to provide the dhcp server with more information to help the server whether a RECONFIGURE is needed. If for some reason, the server detects the same information has been already supplied to the client, it may decide to not generate a RECONFIGURE message.

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.
[Med] I updated my local copy.

Section 3.3 also mentions sending the RSOO, and, if you accept my argument above, should not.
[Med] Changed "MUST" to "MAY" for the reason mentioned above in my local copy.

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.
[Med] I updated Section 3.2 with the proposed text. Thanks.

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