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

From: <[email-masked]>
Date: Fri, 24 Aug 2012 13:49:03 +0200

Dear all,

I submitted a new I-D defining a new message type to trigger a server to issue a RECONFIGURE message when RSSO is used.

The text is available at: https://datatracker.ietf.org/doc/draft-boucadair-dhc-triggered-reconfigure

Comments and suggestions are more than welcome. 

Cheers,
Med

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Aug 2012 13:43:58 +0000

On Aug 24, 2012, at 7:49 AM, [email-masked]<mailto:[email-masked]> 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?

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 24 Aug 2012 16:33:33 +0200

Hi Med,
  I read the draft and I think this is an interesting work.
I have few comments:
- I would suggest adding an informative reference to RFC5176 where you talk about CoA messages;
- I would suggest replacing the Radius Server entity originating Change of Authorization (CoA) Requests with Dynamic Authorization Client (DAC), because according to RFC 5176 "While it is possible that the DAC is co-resident with a RADIUS authentication or accounting server, this need not necessarily be the case."
- minor/editorial: in figures 2 and 3 I would replace AFTR_NAME with  DS-Lite-Tunnel-Name (RFC6519) into the RADIUS messages and OPTION_AFTR_NAME (RFC6334) into the DHCPv6 messages.

Thanks
Best Regards

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: venerdì 24 agosto 2012 13.49
To: [email-masked]
Subject: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure)

Dear all,

Cheers,
Med
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: <[email-masked]>
Date: Fri, 24 Aug 2012 16:39:54 +0200

Dear Ted,

Thank your for the review.

Please see inline.

Cheers,
Med

________________________________
De : Ted Lemon [mailto:[email-masked]]
Envoyé : vendredi 24 août 2012 15:44
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]
Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure)

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.

To this:

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.

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.

[Med] Yes. Thanks.

---

From: <[email-masked]>
Date: Fri, 24 Aug 2012 16:56:21 +0200

Hi Roberta, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

>-----Message d'origine-----
>De : Maglione Roberta [mailto:[email-masked]] 
>Envoyé : vendredi 24 août 2012 16:34
>Cc : Ullio Mario; [email-masked]
>Objet : RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay 
>Agents (draft-boucadair-dhc-triggered-reconfigure)
>
>Hi Med,

Med: Done.

>- I would suggest replacing the Radius Server entity 
>originating Change of Authorization (CoA) Requests with 
>Dynamic Authorization Client (DAC), because according to RFC 
>5176 "While it is possible that the DAC is co-resident with a 
>RADIUS authentication or accounting server, this need not 
>necessarily be the case."

Med: I updated "RADIUS Server" to "RADIUS Server/DAC". 

>- minor/editorial: in figures 2 and 3 I would replace 
>AFTR_NAME with  DS-Lite-Tunnel-Name (RFC6519) into the RADIUS 
>messages and OPTION_AFTR_NAME (RFC6334) into the DHCPv6 messages.

Med: Done. I didn't added a ref to these two RFCs because I want the document be generic and not focus on the example itself. 

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of [email-masked]
>Subject: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents 
>(draft-boucadair-dhc-triggered-reconfigure)
>
>Dear all,
>
>I submitted a new I-D defining a new message type to trigger a 
>server to issue a RECONFIGURE message when RSSO is used.
>
>The text is available at: 
>https://datatracker.ietf.org/doc/draft-boucadair-dhc-triggered-
>reconfigure
>
>Questo messaggio e i suoi allegati sono indirizzati 
>esclusivamente alle persone indicate. La diffusione, copia o 
>qualsiasi altra azione derivante dalla conoscenza di queste 
>informazioni sono rigorosamente vietate. Qualora abbiate 
>ricevuto questo documento per errore siete cortesemente 
>pregati di darne immediata comunicazione al mittente e di 
>provvedere alla sua distruzione, Grazie.
>
>This e-mail and any attachments is confidential and may 
>contain privileged information intended for the addressee(s) 
>only. Dissemination, copying, printing or use by anybody else 
>is unauthorised. If you are not the intended recipient, please 
>delete this message and any attachments and advise the sender 
>by return e-mail, Thanks.
>
>

---

From: Andre Kostur <[email-masked]>
Date: Fri, 24 Aug 2012 08:16:33 -0700

A question that popped into my mind is how does the server decide
whether the client will be doing a Renew, Rebind, or
Information-Request?  Perhaps the RA MUST supply an OPTION_RECONF_MSG?

Also, is the RA expected to monitor the clients as to whether they are
reconfigure capable, or will the RA rely on the server to be watching
that?   Do we want the server to be able to report back to the RA that
the client cannot do Reconfigure?

On Fri, Aug 24, 2012 at 4:49 AM, <[email-masked]> wrote:
>
> Dear all,
>
> I submitted a new I-D defining a new message type to trigger a server to
> issue a RECONFIGURE message when RSSO is used.
>
> https://datatracker.ietf.org/doc/draft-boucadair-dhc-triggered-reconfigure
>

--
Andre Kostur

---

From: <[email-masked]>
Date: Fri, 24 Aug 2012 17:35:14 +0200

Dear Andre,

Please see inline.

Cheers,
Med 

>De : Andre Kostur [mailto:[email-masked]] 
>Envoyé : vendredi 24 août 2012 17:17
>Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay 

Med: What I had initially in mind for this new message: is to not require any change to the way RECONFIGURE is managed by the server but only provide a signal to the DHCPv6 server to issue one. Is there any particular reason you think the RA should be involved in that process?

>that?

Med: I would say no.

   Do we want the server to be able to report back to the RA that
>the client cannot do Reconfigure?

Med: I would say no.

---

From: Andre Kostur <[email-masked]>
Date: Fri, 24 Aug 2012 08:47:51 -0700

Normally the server is being told administratively to reconfigure a
client, and presumably which of the three methods to use.  This is
just another form of that.   I could see it being changed to: the RA
MAY supply an OPTION_RECONF_MSG, and if not supplied, the server may
determine which form of Reconfigure to use.

-- 
Andre Kostur
Senior Product Design Engineer
P: 604-678-2864
E: [email-masked]
Toll-Free: 1-800-877-1856

F: 604-678-2864
VoIP: sip:[email-masked]

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Sun, 26 Aug 2012 14:41:20 +0000

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.

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 I.D which is also proposing to add Rebind capability triggered by RECONFIGURE message. (draft-droms-dhc-dhcpv6-solmaxrt-update-03). So it would certainly be useful to include OPTION_RECONF_MSG on this message.

Thanks,
Gaurav

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

Dear Ted,

Please see inline.

Cheers,
Med

________________________________
De : Ted Lemon [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Envoyé : vendredi 24 août 2012 15:44
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure)
On Aug 24, 2012, at 7:49 AM, [email-masked]<mailto:[email-masked]> wrote:
Comments and suggestions are more than welcome.

To this:

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Sun, 26 Aug 2012 14:47:38 +0000

Specifying the correct reference to RFC.

Hi Med,

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.

Thanks,
Gaurav

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

Dear Ted,

Please see inline.

Cheers,
Med

To this:

---

From: <[email-masked]>
Date: Mon, 27 Aug 2012 07:26:13 +0200

Dear Andre,

I see the point. 

I updated the text accordingly. 

Thanks.

Cheers,
Med 

>Envoyé : vendredi 24 août 2012 17:48
>> Med: What I had initially in mind for this new message: is 
>to not require any change to the way RECONFIGURE is managed by 
>the server but only provide a signal to the DHCPv6 server to 
>issue one. Is there any particular reason you think the RA 
>should be involved in that process?
>>
>>>

---

From: <[email-masked]>
Date: Mon, 27 Aug 2012 07:38:03 +0200

Dear Gaurav,

Please see inline.

Cheers,
Med

________________________________
De : Gaurav Halwasia (ghalwasi) [mailto:[email-masked]]
Envoyé : dimanche 26 août 2012 16:48
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Ted Lemon
Cc : [email-masked]
Objet : RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure)

Hi Med,

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

Dear Ted,

Please see inline.

Cheers,
Med

To this:

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Mon, 27 Aug 2012 05:40:50 +0000

Hi Med,

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

Thanks,
Gaurav
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, August 27, 2012 11:08 AM
To: Gaurav Halwasia (ghalwasi); Ted Lemon
Cc: [email-masked]
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:[email-masked]]<mailto:[mailto:[email-masked]]>

Hi Med,

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

Dear Ted,

Please see inline.

Cheers,
Med

To this:

---

From: <[email-masked]>
Date: Mon, 27 Aug 2012 10:29:08 +0200

Re-,

Ok, thanks.

FYI, I submitted an updated version integrating the comments received so far. This version is available at: http://tools.ietf.org/html/draft-boucadair-dhc-triggered-reconfigure-01.

Cheers,
Med

Envoyé : lundi 27 août 2012 07:41

Hi Med,

Thanks,
Gaurav

Dear Gaurav,

Please see inline.

Cheers,
Med

Hi Med,

Thanks,
Gaurav

Dear Ted,

Please see inline.

Cheers,
Med

To this: