Subject: [dhcwg] Comments on draft-yeh-dhc-dhcpv6-authorization-opt-00

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 09 Apr 2012 00:06:40 +0200

Hi,
I finally found some time to read the draft. I do support this work and
its adoption (if requested), but I suggest several changes to the text.

First and foremost, I agree with Ted's and Bernie's comments. Please
pick design 2 and make this a single option that is a container for any
Radius options.

Here's my opinion why design 1 is very bad. For specific use cases
author chose 2 options: pool name and prefix auth, but I'm sure there
are cases when other Radius attributes may be useful. There are 160
Radius attributes defined so far. Please do not turn this into one to
one Radius to DHCPv6 option translator. Much better approach is to
define a single container that conveys required Radius attributes. Don't
worry about extra processing required on DHCPv6 server side. Many
servers are smart enough to do processing of received options. For
example ISC DHCP is able to play various tricks like fancy to string
conversion, sub-string search etc. I'm sure other implementations can do
similar processing.

Also, that is the same approach that was chosen for DHCPv4 (as defined
in RFC4014). It works in v4 and the principles are the same, so keep it
the same in v6. Having one container option is also forward compatible
with any new radius options that may be defined in the future.

1. Introduction - I'm not sure if introductory paragraph about DHCPv6
with all references to all those RFCs is needed. If you think that is
useful, a one short sentence with reference to 3315 will do the trick.
If you really want to keep those references, make most of them
informative. Normative references are the ones that are required to
understand your proposal. In this context RFC3646 is informative as it
only provides background information.

I think simple reference to primary Radius IPv6 RFC will do as well. I'm
not a Radius expert, so it you think that keeping those detailed
references are useful, I won't object. Please consider if all of them
must be kept normative, though. Perhaps informative will be enough.

2. I would strongly suggest to rename that option to OPTION_RADIUS. This
name will instantly tell everyone what that option conveys.
Authorization may mean many different things in different contexts.

3. In option format specified in Section 4, option name is typically
written in all uppercase (OPTION_AUTHORIZATION rather than
Option_Authorization).

4. Section that defines an option often briefly specifies it usage. It
may be useful to add couple of sentences there: Client MUST NOT send
this option. Client MUST ignore this option if received. Relays MAY
include this option in RELAY-FORW messages. Server SHOULD NOT/MUST NOT
include it in RELAY-REPL messages.

5. I would reword first sentence in "Relay Agent Behavior" (section 6).
"The DHCPv6 relay agent must include Option_Authorization in the
relay-forward (12) message..." => "The DHCPv6 relay agent that supports this
mechanism SHOULD include OPTION_RADIUS in the relay-forward message...".
(SHOULD instead of must).

6. It would be useful to say that relay does not have to include all
RADIUS attributes, just those that would be useful.

7. Negative case. I'm not sure if I understand that correctly, but what
happens if a client is not authorized by Radius? Should relay drop the
message? Or do you want relay to forward client's message with the
negative radius response and finally server is expected to not assign
addresses/prefixes? Some kind of clarification about that could be useful.

8. In section 6. you should also mention that relay MUST ignore received
incoming OPTION_RADIUS (server should not echo it back, right?).

9. In "Server Behavior" section it is better to say: "The DHCPv6 server
MAY use received RADIUS option to pick appropriate addresses, options
and delegate prefixes.".

10. I assume that server does not echo RADIUS option back, right?
Something to that effect should be added in Section 7. Also, in Fig. 1
you could add extra space between (Option_Authorization) and Relay-reply
lines to show that Authorization/Radius option is expected to appear in
relay-forward message only, not in both relay-forward and relay-reply.

11. While clients are not expected to ever see this option, it would be
explicitely state that using normative language. Something like "Client
MUST NOT send RADIUS option. Client MUST ignore received RADIUS option."

12. Are there any security considerations that are specific to RADIUS?
You should probably point to a security considerations section in some
RADIUS RFC.

13. As a sole author, I'm not sure if that makes sense to mark your role
as editor.

Despite quite a few comments, I support this work. It looks useful and
I'm quite surprised that RADIUS option was not defined yet.

Cheers,
Tomek

---

From: Leaf yeh <[email-masked]>
Date: Sat, 21 Apr 2012 10:06:02 +0000

Hi Tomek, 

First and foremost, thanks for your constructive comments in detail. Really appreciated.

The following are the reply to your comments.

Tomek- I agree with Ted's and Bernie's comments. Please pick design 2 and make this a single option that is a container for any Radius options.

Design-2 (same as RFC4014) sounds a simpler selection for us in the design, but it will couple with the RADIUS attributes (or protocol), because the DHCPv6 server will take responsibility to interpret these RADIUS attributes. RADIUS attributes (or protocol) will extend to have some new kind of 'basic data type', e.g. nesting TLV, per draft-ietf-radext-radius-extensions, because the unassigned standard type space (161-190) will soon exhausted. DHCPv6 options support multi-fields design natively, but RADIUS does not before. Supposed ISC & Cisco might already support RFC4014, and that make you tend to prefer design-2. But as a native DHC guy, I preferred design-1 before. 

Anyway, I will follow your (Bernie & you) comments to use Design-2 in draft-yeh-01 for the further step & discussion.

Tomek - For specific use cases author chose 2 options: pool name and prefix auth, but I'm sure there are cases when other Radius attributes may be useful. There are 160
Radius attributes defined so far.

When I pick a list of IPv6 RADIUS attributes from http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-1 as RFC4014 did before, (which only picked 6 RADIUS attributes), only the following limited code numbers are involved in the draft-yeh-01.

Type Code    Attribute                     Reference
26           Vendor-Specific               RFC2865
88           Framed-Pool                   RFC2869
123          Delegated-IPv6-Prefix         RFC4818
TBD          Framed-IPv6-Address           ietf-radext-ipv6-access-06

Hope we could find more. I can't even find RADIUS attribute associated with DNS in the assigned standard space, though Huawei-VSA (26) has supported it.

Tomek - 1. Introduction - I'm not sure if introductory paragraph about DHCPv6 with all references to all those RFCs is needed. If you think that is useful, a one short sentence with reference to 3315 will do the trick. If you really want to keep those references, make most of them informative. Normative references are the ones that are required to understand your proposal. In this context RFC3646 is informative as it only provides background information.

Accepted in draft-yeh-01. I moved RFC3162, RFC3633, RFC3646 into Informative References (section 11.2).

Tomek - 2. I would strongly suggest to rename that option to OPTION_RADIUS. This name will instantly tell everyone what that option conveys. Authorization may mean many different things in different contexts.

Accepted in draft-yeh-01, though I though the this option is only associated to the 2nd A in the AAA server (=RADIUS server) here. :-)

Tomek - 3. In option format specified in Section 4, option name is typically written in all uppercase (OPTION_AUTHORIZATION rather than Option_Authorization).

Accepted, OPTION_RADIUS will appear in draft-yeh-01.

Tomek - 4. Section that defines an option often briefly specifies it usage. It may be useful to add couple of sentences there: Client MUST NOT send this option. Client MUST ignore this option if received. Relays MAY include this option in RELAY-FORW messages. Server SHOULD NOT/MUST NOT include it in RELAY-REPL messages.

Accepted in draft-yeh-01.

Tomek - 5. I would reword first sentence in "Relay Agent Behavior" (section 6). "The DHCPv6 relay agent must include Option_Authorization in the relay-forward (12) message..." => "The DHCPv6 relay agent that supports this mechanism SHOULD include OPTION_RADIUS in the relay-forward message...".(SHOULD instead of must).

Accepted in draft-yeh-01.

Tomek - 7. Negative case. I'm not sure if I understand that correctly, but what happens if a client is not authorized by Radius? Should relay drop the message? Or do you want relay to forward client's message with the negative radius response and finally server is expected to not assign addresses/prefixes? Some kind of clarification about that could be useful.

I think the Fig.1 or Fig.2 will answer this question. If the authorization through RADIUS fails, then the message sequence shown in the figures will stop. The relay will not forward the message from the client. Will clarified in section 3 of draft-yeh-01.

Tomek - 8. In section 6. you should also mention that relay MUST ignore received incoming OPTION_RADIUS (server should not echo it back, right?).

Yes, the server will not be necessary to echo OPTION_RADIUS back, the reason is the Access-Accept of RADIUS need not to be replied. Accepted in draft-yeh-01. 

Tomek - 9. In "Server Behavior" section it is better to say: "The DHCPv6 server MAY use received RADIUS option to pick appropriate addresses, options and delegate prefixes.".

How about the following text: "After the RELAY-FORW message with OPTION_RADIUS arrived, the DHCPv6 server SHOULD extract and interpret the RADIUS attributes in the OPTION_RADIUS, and use that information in selecting configuration parameters for the client. If the DHCPv6 server does not support OPTION_RADIUS yet, the DHCPv6 server MAY ignore this option."?

Tomek - 10. Something to that effect should be added in Section 7. Also, in Fig. 1 you could add extra space between (Option_Authorization) and Relay-reply lines to show that Authorization/Radius option is expected to appear in relay-forward message only, not in both relay-forward and relay-reply.

Accepted in draft-yeh-01.

Tomek - 12. Are there any security considerations that are specific to RADIUS? You should probably point to a security considerations section in some RADIUS RFC.

Accepted in draft-yeh-01.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Monday, April 09, 2012 6:07 AM
To: DHC WG
Subject: [dhcwg] Comments on draft-yeh-dhc-dhcpv6-authorization-opt-00

Hi,

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