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

From: [email-masked]
Date: Thu, 29 Nov 2012 04:13:14 -0800

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-05.txt
	Pages           : 9
	Date            : 2012-11-29

Abstract:
   The DHCPv6 RADIUS option provides a mechanism to exchange
   authorization and identification information between relay agent and
   server.  This mechanism is meant for 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 Network Access Server
   (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-05

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

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

---

From: "Leaf Yeh" <[email-masked]>
Date: Thu, 29 Nov 2012 20:21:02 +0800

Hi folks,

Draft (OPTION_RADIUS) has been updated to ver.-05, which solved the
editorial comments from Roberta Maglione and Bernie Volz on the ML of DHC.
The updates can be found at
http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-radius-opt-05  .

The draft (OPTION_RADIUS) of ver.-05 got the following text changes from
ver. -04:

a.  Change the text to be "Note: The definition of the RADIUS attribute's
'Length' field in section 5 of [RFC2865] includes the length of 'Type' and
'Length' fields." in section 4 ; 
b.  Add the text of 'New RADIUS attributes may be added to this list after
the IETF Expert Review RFC5226].' in section 4 ; 
c.  Replace 'IETF Review' to be 'IETF Expert Review' in section 9 ; 
d.  Replace 2x 'Should' to be 'SHOULD', and replace 4x 'may' to be 'MAY' in
the text body;

Has it been ready to submit to IESG?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, November 29, 2012 8:13 PM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-05.txt

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-05.txt
	Pages           : 9
	Date            : 2012-11-29

Abstract:

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

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 30 Nov 2012 18:27:14 +0100

>    (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in

Here are my comments:

Abstract:

I think abstract could be a bit more precise in first sentence.
Typically "relay agent" and "server" are obvious in the DHCP context,
but when radius is mixed in, it is better to refer to them as DHCPv6
server and DHCPv6 relay. (I don't know much about radius, but googling
for "radius relay" returns over 26 millions pages...)

Section 1:
"In this document, the DHCPv6 server is deployed in the central part of
an ISP network." => "In the scenario described in this document, ..."

Section 2, first sentence:
The word distributed is unclear in this context. I think it should be
removed (or clarified what you have in mind, as there is no such thing
as distributed relay agent).

Section 3:
"Figure 1 and Figure 2 shows" => "Figure 1 and Figure 2 show"

IPoE is not defined before. I presume it is IP over Ethernet, but it is
not defined in this draft, RFC2865 or 3315, so you should explain it. On
a related note, does it matter at all? Would the mechanism change if I
wanted to deploy it over other access technology? I think not. A simple
clarification that IPoE is just an example and this will work the same
way for other access technologies would be helpful here. Perhaps you can
remove "IPoE" comment altogether?

In figure 1, I would position radius server and DHCPv6 server boxes
differently. Aligning them one directly above another may give the
impression that they are the same. The same applies to Figure 2.

In the paragraph below Figure 2 there is a discussion when NAS should
and shouldn't exchange data with radius server. Shouldn't that be a
normative language (capital SHOULD/SHOULD NOT instead of "has"/"does not
have")?

General comment after figure 1 and 2:
It would be useful to note somewhere that NAS keeps the information
retrieved over radius, so it can be later used when REQUEST is relayed.
That is perhaps obvious for people dealing with NAS, but statefulness vs
statelessness is a touchy topic in DHCP world. It is better to state it
clearly that this makes the relay stateful. There is nothing wrong with
it, but it should be clear for implementors as this is significant
change, compared to "normal" dhcpv6 relay, which is completely
stateless. This comment should likely go to section 5.

Section 4.
Agree with previous Bernie's comments: There's no such thing as
stateless option. See my suggestion about clarifying if this RADIUS
option may appear when relaying inf-request and other messages.

Couple comments about this sentence: "Only the attributes listed in the
IANA Registry of 'RADIUS Attributes Permitted in the DHCPv6 RADIUS
option' SHOULD be included in the OPTION_RADIUS."

1. It should be MAY, not SHOULD. SHOULD is almost as strong as MUST,
unless there are very good reasons not to. In the current form this
sentence means: you must send every attribute from the permitted
attributes list, unless there is very good reason to do otherwise and
all consequences of not sending it are understood. I'm sure that is not
what you meant.

2. Is this really a good idea to define such a list? Some folks may
have odd, but valid policies and would like to use other radius
attributes. Let me give an example. If I ever run access network, I'll
make sure that a user with user-name equal to tomek will get a special
prefix, so I'd like my relay to convey User-Name attribute. Strange,
perhaps insecure, but valid policy. Unfortunately, your current draft
forbids that.

3. Having such a list is rather error-prone. I'm not sure how radext WG
is organized, but I'm sure that sooner or later someone will forget to
add a statement in his/her draft to add newly defined parameter to the
list and it won't be allowed to be included in DHCP option.

My point is that I would prefer to not have such a list at all. I would
reword the text that in normal case attributes listed at the end of
section 4 are useful. Other attributes may appear if they are needed.

Section 5:
This section lists radius parameters by name. What about new attributes?
It should say "all parameters from the Permitted Radius Attributes" or
something along that lines.

This section should state that relay (or NAS) should keep relay
responses received during SOLICIT processing, so they will be reused in
REQUEST. In fact, it should be defined how long relay/nas is supposed to
keep that information. What about RENEWs? It should be clarified if
OPTION_RADIUS should be included just in SOLICIT/REQUEST or in other
relayed messages as well (REBIND, DECLINE, CONFIRM, RELEASE, INF-REQUEST).

Section 6:
"If the DHCPv6 server does not support OPTION_RADIUS, the DHCPv6 server
MUST silently discard this option." Server discards any unrecognised
options. It is a repetition of RFC3315, but it is good to have it for
clarity.

Section 7:
"OPTION_RADIUS is only exchanged between the relay agents and the
servers." Not true. Relays send this option to servers. Servers never
send it back. At least that's my understanding. Why was this changed
between -04 and -05? Previous text was ok.

Section 8:
You should add that by successfully attacking the relay you can
influence legitimate server to alter its policy. Once you have your
relay compromised you are likely to have bigger problems anyway, but
this should probably be mentioned.

Sorry for posting my comments so late, but I was on vacation. Is the
WGLC still in progress or concluded already? If it is still on-going, I
support this document going forward.

Cheers,
Tomek