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

[<[e-mail]>]

Dear Ted,

Thank your for the review.

Please see inline.

Cheers,
Med

________________________________
De : Ted Lemon [mailto:[e-mail]]
Envoyé : vendredi 24 août 2012 15:44
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [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.