Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt

From: [email-masked]
Date: Sun, 21 Oct 2012 19:30:22 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title           : RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server
	Author(s)       : Leaf Y. Yeh
                          Mohamed Boucadair
                          Ted Lemon
	Filename        : draft-ietf-dhc-dhcpv6-radius-opt-03.txt
	Pages           : 9
	Date            : 2012-10-21

Abstract:
   The DHCPv6 RADIUS option provides a mechanism to exchange
   authorization and identification information between relay agent and
   server.  This mechanism is meant to the centralized DHCPv6 server to
   select the right configuration for the requesting client based on the
   authorization information received from the RADIUS server, which is
   not co-located with the DHCPv6 server.  The NAS acts as DHCPv6 relay
   agent and RADIUS client simultaneously in this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-radius-opt-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Leaf yeh <[email-masked]>
Date: Mon, 22 Oct 2012 02:40:50 +0000

Dear folks,

Supposed it is ready for your thorough review again. Your further comments are more than welcome. :-)

BTW, there is no meaningful change from ver.-02 to ver.-03, just some expression in text. But there has some changes from ver.-01 to ver.-02.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 22, 2012 10:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt

Abstract:

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

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Mon, 22 Oct 2012 07:01:41 +0000

Hi Leaf,

This is a useful work and I do support this work. I have few comments though.

* Abstract says, " This mechanism is meant to the centralized DHCPv6 server to select the right configuration for the requesting client ... ". Does not it say " This mechanism is meant for the centralized DHCPv6 server .." .?

* Section 4 heading could say "DHCPv6 OPTION_RADIUS option"

* Section 4 says, " only the attributes listed in the table below may be included in the OPTION_RADIUS ". What about any other attributes which might be required in future.? Are you suggesting that a new specification will be required to include any other attribute in DHCPv6 RADIUS_OPTION option.? IMO,  keeping the attribute list open for the implementer will increase the usability of this mechanism. I think this specification can just mention the attributes as one of the use-case. 

* Section 5, "Relay Agent Behavior" says " The relay agent MUST silently discard OPTION_RADIUS
   if received. ". Can you explain about it little more and what is your proposal keeping "Relay Chaining" in mind.?

Thanks,
Gaurav
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leaf yeh
Sent: Monday, October 22, 2012 8:11 AM
To: [email-masked]
Cc: Bernie Volz (volz); Tomek Mrugalski
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt

Dear folks,

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 22, 2012 10:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt

Abstract:

---

From: Leaf yeh <[email-masked]>
Date: Mon, 22 Oct 2012 12:30:10 +0000

Hi Gaurav,

Thanks for your valuable comments. The following are my instant reply:

Gaurav -* Abstract says, " This mechanism is meant to the centralized DHCPv6 server to select the right configuration for the requesting client ... ". Does not it say " This mechanism is meant for the centralized DHCPv6 server .." .?

Editorial. Accepted, the text of "is meant for" sounds fine with me. 

Gaurav - * Section 4 heading could say "DHCPv6 OPTION_RADIUS option"

Editorial. How about "DHCPv6 RADIUS option"? 

Gaurav - * Section 4 says, " only the attributes listed in the table below may be included in the OPTION_RADIUS ". What about any other attributes which might be required in future.? Are you suggesting that a new specification will be required to include any other attribute in DHCPv6 RADIUS_OPTION option.? IMO,  keeping the attribute list open for the implementer will increase the usability of this mechanism. I think this specification can just mention the attributes as one of the use-case. 

Editorial. I adopted the roughly same text in my draft as that in the section 4 of RFC4014.

 <quote>To avoid dependencies between the address allocation and other state
   information between the RADIUS server and the DHCP server, the DHCP
   relay agent SHOULD include only the attributes in the table below in
   an instance of the RADIUS Attributes suboption.</quote>

I need consult with the chair to work out a solution for your concern.

Gaurav -* Section 5, "Relay Agent Behavior" says " The relay agent MUST silently discard OPTION_RADIUS
   if received. ". Can you explain about it little more and what is your proposal keeping "Relay Chaining" in mind.?

Technical. Good point. How about ''The relay agent MUST silently discard OPTION_RADIUS if received in the RELAY-REPL (13) message." 

Best Regards,
Leaf

-----Original Message-----
From: Gaurav Halwasia (ghalwasi) [mailto:[email-masked]] 
Sent: Monday, October 22, 2012 3:02 PM
To: Leaf yeh; [email-masked]
Cc: Bernie Volz (volz); Tomek Mrugalski
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt

Hi Leaf,

Thanks,
Gaurav
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leaf yeh
Sent: Monday, October 22, 2012 8:11 AM
To: [email-masked]
Cc: Bernie Volz (volz); Tomek Mrugalski
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt

Dear folks,

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 22, 2012 10:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt

Abstract:

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Mon, 22 Oct 2012 12:47:59 +0000

Gaurav - * Section 4 heading could say "DHCPv6 OPTION_RADIUS option"
Editorial. How about "DHCPv6 RADIUS option"? 
[Gaurav] Yes, this looks good as well. Just "OPTION_RADIUS" was looking odd.

I need consult with the chair to work out a solution for your concern.
[Gaurav] I understand you have borrowed this text from RFC4014. But I still think that keeping the attribute space unrestricted will be good.  Anyhow, let me know when you arrive at any conclusion regarding this based upon your discussion with chair.

Technical. Good point. How about ''The relay agent MUST silently discard OPTION_RADIUS if received in the RELAY-REPL (13) message." 
[Gaurav] I am fine with this text.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 22 Oct 2012 15:24:57 +0000

Hi:

In general this looks very good now. And, I (mostly) agree with the changes proposed.

I would suggest the following minor changes:

- In section 4, please indicate that the "one or a list of RADIUS Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type and length and that the length includes the length octet?

- Looks like the text "As the same method in [RFC4014], ..." has been replaced with the text mentioned below? Good if that is the case as I am not sure what "same method" really meant. Please also drop "Note: The above table might have more attributes to join in the future." if that wasn't already done.

I believe that future RADIUS Attribute documents can update this document if the attribute(s) are to be allowed in this option in the future. Perhaps IANA could maintain a registry of the RADIUS attributes allowed in the option; but I don't think we requested this for v4 and not sure it is really needed for v6.

- Regarding ... how about ''The relay agent MUST silently discard OPTION_RADIUS if received in the RELAY-REPL (13) message."

Do you really want to specify this? The server is not supposed to echo back options. BUT we do have the Echo Request Option (ERO, 43) which a relay could use to request this information back if it needed it for some reason. So, I don't see a need to require this MUST and I think you should be silent about it -- I would thus just remove the last sentence of the paragraph in section 5.

Though we also should fix the text in 6. Server Behavior. The last sentence of:

   The DHCPv6 server MUST NOT include OPTION_RADIUS in RELAY-REPL (13) messages.

Should either be dropped or changed to read:

   The DHCPv6 server MUST NOT include the OPTION_RADIUS in RELAY-REPL (13) messages unless requested by the relay agent in the Echo Request Option (OPTION_ERO).

- Bernie

---

From: Leaf yeh <[email-masked]>
Date: Tue, 23 Oct 2012 09:57:27 +0000

Hi Bernie,

Thanks for your valuable comments.

Bernie - In section 4, please indicate that the "one or a list of RADIUS Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type and length and that the length includes the length octet?

Editorial. The format of the RADIUS attribute in the traditional type space is defined in section 5 of RFC2865. The format of the RADIUS attribute in the extended type space is defined in section 2 of draft-ietf-radext-radius-extensions. The definition of their 'Length' field are identical for the length of the whole attribute including the TLV fields of 'Type', 'Length', 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'. I'd like OPTION_RADIUS could also include the attributes defined in the future which employed the extended type space, but have no objection to your suggestion for the clarification on the 'length' field of RADIUS attribute. 

How about add a note after the table as follows: 'Note: The one-octet 'Length' field in the RADIUS attribute indicates the length of the whole attribute.' ?

Bernie - Looks like the text "As the same method in [RFC4014], ..." has been replaced with the text mentioned below? Good if that is the case as I am not sure what "same method" really meant. Please also drop "Note: The above table might have more attributes to join in the future." if that wasn't already done.

Editorial. I am fine to drop the text of ' As the same method in [RFC4014],' and 'Note: The above table might have more attributes to join in the future.'

Bernie - So, I don't see a need to require this MUST and I think you should be silent about it -- I would thus just remove the last sentence of the paragraph in section 5.

Editorial. Accepted if ERO (43) sounds a concern.

Bernie - Should either be dropped or changed to read:

Editorial. I tend to drop the last sentence in section 6, because I have not seen the use case (or necessity) to introduce ERO (43) here.

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Monday, October 22, 2012 11:25 PM
To: Gaurav Halwasia (ghalwasi); Leaf yeh; [email-masked]
Cc: Tomek Mrugalski
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt

Hi:

- Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 23 Oct 2012 11:28:00 +0000

For issue about Radius attributes, why not just include those cross references?

Sent from my iPad

---

From: Leaf yeh <[email-masked]>
Date: Tue, 23 Oct 2012 11:33:24 +0000

Bernie - For issue about Radius attributes...

What do you mean for the 'issue'? 

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Tuesday, October 23, 2012 7:28 PM
To: Leaf yeh
Cc: Gaurav Halwasia (ghalwasi); [email-masked]; Tomek Mrugalski
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt

Sent from my iPad

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 23 Oct 2012 11:34:28 +0000

Sent from my iPad

---

From: Leaf yeh <[email-masked]>
Date: Tue, 23 Oct 2012 11:44:21 +0000

How about add a note after the table in section 4 as follows: 'Note: The one-octet 'Length' field in the RADIUS attribute defined in section 5 of RFC2865, indicates the length of the whole attribute' ?

<quote> draft-ietf-radext-radius-extensions @ http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/?include_text=1 - section 2.1 + 2.2 :
Length
      This field is identical to the Length field of the Attribute
      format defined in [RFC2865] Section 5.
</quote>

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Tuesday, October 23, 2012 7:34 PM
To: Leaf yeh
Cc: [email-masked]; Tomek Mrugalski
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt

Sent from my iPad

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 23 Oct 2012 13:12:40 +0000

I don't like "whole attribute" ... What does that mean? It may be best to just ref the Radius documents. Perhaps a note that "While RADIUS uses TLV encoding for attributes as DHCP does for options, the L (length) for RADIUS attributes is defined differently than for DHCP options."

Sent from my iPad

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 23 Oct 2012 22:04:07 +0800

3rd - How about 'Note: The definition of the RADIUS attribute's 'Length'
field in section 5 of RFC2865 is different from that of DHCPv6 option's
option-length field defined here.' ?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernie Volz (volz)
Sent: Tuesday, October 23, 2012 9:13 PM
To: Leaf yeh
Cc: [email-masked]; Tomek Mrugalski
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt

I don't like "whole attribute" ... What does that mean? It may be best to
just ref the Radius documents. Perhaps a note that "While RADIUS uses TLV
encoding for attributes as DHCP does for options, the L (length) for RADIUS
attributes is defined differently than for DHCP options."

Sent from my iPad

On Oct 23, 2012, at 7:45 AM, "Leaf yeh" <[email-masked]> wrote:

> How about add a note after the table in section 4 as follows: 'Note: The
one-octet 'Length' field in the RADIUS attribute defined in section 5 of
RFC2865, indicates the length of the whole attribute' ?
> 
> 
> <quote> draft-ietf-radext-radius-extensions @
http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/?include
_text=1 - section 2.1 + 2.2 :
>>> Bernie - In section 4, please indicate that the "one or a list of RADIUS
Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type
and length and that the length includes the length octet?
>>> 
>>> Editorial. The format of the RADIUS attribute in the traditional type
space is defined in section 5 of RFC2865. The format of the RADIUS attribute
in the extended type space is defined in section 2 of
draft-ietf-radext-radius-extensions. The definition of their 'Length' field
are identical for the length of the whole attribute including the TLV fields
of 'Type', 'Length', 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'.
I'd like OPTION_RADIUS could also include the attributes defined in the
future which employed the extended type space, but have no objection to your
suggestion for the clarification on the 'length' field of RADIUS attribute.
>>> Bernie - In section 4, please indicate that the "one or a list of RADIUS
Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type
and length and that the length includes the length octet?
>>> 
>>> Editorial. The format of the RADIUS attribute in the traditional type
space is defined in section 5 of RFC2865. The format of the RADIUS attribute
in the extended type space is defined in section 2 of
draft-ietf-radext-radius-extensions. The definition of their 'Length' field
are identical for the length of the whole attribute including the TLV fields
of 'Type', 'Length', 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'.
I'd like OPTION_RADIUS could also include the attributes defined in the
future which employed the extended type space, but have no objection to your
suggestion for the clarification on the 'length' field of RADIUS attribute. 
>>> 
>>> How about add a note after the table as follows: 'Note: The one-octet
'Length' field in the RADIUS attribute indicates the length of the whole
attribute.' ?
>>> 
>>> 
>>> Bernie - Looks like the text "As the same method in [RFC4014], ..." has
been replaced with the text mentioned below? Good if that is the case as I
am not sure what "same method" really meant. Please also drop "Note: The
above table might have more attributes to join in the future." if that
wasn't already done.
>>> 
>>> Editorial. I am fine to drop the text of ' As the same method in
[RFC4014],' and 'Note: The above table might have more attributes to join in
the future.'
>>> 
>>> 
>>> Bernie - So, I don't see a need to require this MUST and I think you
should be silent about it -- I would thus just remove the last sentence of
the paragraph in section 5.
>>> Editorial. I tend to drop the last sentence in section 6, because I have
not seen the use case (or necessity) to introduce ERO (43) here.
>>> - In section 4, please indicate that the "one or a list of RADIUS
Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type
and length and that the length includes the length octet?
>>> 
>>> - Looks like the text "As the same method in [RFC4014], ..." has been
replaced with the text mentioned below? Good if that is the case as I am not
sure what "same method" really meant. Please also drop "Note: The above
table might have more attributes to join in the future." if that wasn't
already done.
>>> 
>>> I believe that future RADIUS Attribute documents can update this
document if the attribute(s) are to be allowed in this option in the future.
Perhaps IANA could maintain a registry of the RADIUS attributes allowed in
the option; but I don't think we requested this for v4 and not sure it is
really needed for v6.
>>> 
>>> - Regarding ... how about ''The relay agent MUST silently discard
OPTION_RADIUS if received in the RELAY-REPL (13) message."
>>> 
>>> Do you really want to specify this? The server is not supposed to echo
back options. BUT we do have the Echo Request Option (ERO, 43) which a relay
could use to request this information back if it needed it for some reason.
So, I don't see a need to require this MUST and I think you should be silent
about it -- I would thus just remove the last sentence of the paragraph in
section 5.
>>> The DHCPv6 server MUST NOT include the OPTION_RADIUS in RELAY-REPL (13)
messages unless requested by the relay agent in the Echo Request Option
(OPTION_ERO).
>>> Gaurav - * Section 4 says, " only the attributes listed in the table
below may be included in the OPTION_RADIUS ". What about any other
attributes which might be required in future.? Are you suggesting that a new
specification will be required to include any other attribute in DHCPv6
RADIUS_OPTION option.? IMO,  keeping the attribute list open for the
implementer will increase the usability of this mechanism. I think this
specification can just mention the attributes as one of the use-case. 
>>> <quote>To avoid dependencies between the address allocation and 
>>> other state information between the RADIUS server and the DHCP 
>>> server, the DHCP relay agent SHOULD include only the attributes in 
>>> the table below in an instance of the RADIUS Attributes 
>>> suboption.</quote>
>>> 
>>> [Gaurav] I understand you have borrowed this text from RFC4014. But I
still think that keeping the attribute space unrestricted will be good.
Anyhow, let me know when you arrive at any conclusion regarding this based
upon your discussion with chair.
>>> 
>>> Gaurav -* Section 5, "Relay Agent Behavior" says " The relay agent 
>>> MUST silently discard OPTION_RADIUS if received. ". Can you explain
about it little more and what is your proposal keeping "Relay Chaining" in
mind.?
>>> 
>>> Technical. Good point. How about ''The relay agent MUST silently discard
OPTION_RADIUS if received in the RELAY-REPL (13) message."