Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-radius-opt-05.txt

From: Leaf yeh <[email-masked]>
Date: Tue, 4 Dec 2012 11:45:02 +0000

Tomek - 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.

Accepted. I will add 'DHCPv6' before each of the DHCPv6 server, relay agent and client in the Abstract.

Tomek - 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, ..."

Adopted, the text will be 'In the scenarios described ...'.

Tomek - 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).

Accepted. The relay agent sounds 'distributed' natively. In this regard, it sounds no need to employ the word 'distributed' here. In fact, I have no much in my mind. If you care, I will replace the 'the distributed Relay Agent ' to be 'the DHCPv6 Relay Agent'.

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

Appreciate and will doubtless accept this revision.

Tomek - 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.

IPoE means IP over Ethernet, which is borrowed from Broadband Forum TR-177. I guess it is a well-known word and it means a well-known access model. It does 'represents the scenario when the access loop supports direct Ethernet encapsulation'. Per the description in BBF TR-177 & TR-187, IPoE and PPPoE are 2 typical network models.
How about update the text to be 'Figure 1 shows the sequence of DHCPv6 and RADIUS messages for IP over Ethernet (IPoE) access model, when the access loop adopts the direct Ethernet encapsulation' ?

Tomek - 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?

When the access model changes, the message sequences in the Fig.1 of IPoE look differently with the Fig.2 of PPPoE. 

Tomek - 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.

The 1st sentence in section 3 has said that 'In these scenarios, the centralized DHCPv6 server is not co-located with the RADIUS server,...'

Tomek - 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")?

Accepted. I will change the text to be 'SHOULD/SHOULD NOT' if you care. It seems to me the roughly same mechanism was introduced by section 3 of RFC6519, but we have DHCPv6 relay here. The text in section 3 of RFC6519 has 1x 'does not have' and 1x 'MUST'. Your further opinion?

Tomek - 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.

Appreciate your carefulness. I tend not to touch the word of 'stateful', but could make the clarification after Fig. 2 in section 3 as follows: 'If the authentication or the authorization through RADIUS passes, the NAS MUST store the RADIUS attributes received in the Access-Accept message from the RADIUS server during the whole session.' I regard this is the part of the RADIUS protocol.

Tomek - 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.

I will remove the word of 'stateless' if your guys really care. 

Tomek - 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.

Section 4 of RFC4014 used the word of 'SHOULD'.
The option doesn't send 'every attribute', but one or more RADIUS attributes in the recommended list.

Tomek - 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.

In your example, the NAS gets the 'special prefix' in the attribute of Delegated-IPv6-Prefix (123) from the RADIUS server. Then the relay only need to convey the Delegated-IPv6-Prefix (123) to the server. I meant the relay don't need to convey 'User-Name (1)' through this option to the server, if it is regarded only for the RADIUS server.

Tomek - 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.

I guess the group of AAA-Doctors might need someone who can understand DHCPv6.

Tomek - 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.

The draft has the text of 'New RADIUS attributes MAY be added to this list after the IETF Expert Review [RFC5226].' in section 4.

Tomek - 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).

As mentioned above, NAS will keep the RADIUS attributes received in the Access-Accept message during the whole session. 
Per the text in the draft now, the relay may include OPTION_RADIUS in RELAY-FORW for each kind of message from client to server. 
If we intend to figure out which message from the client need the relay include OPTION_RADIUS, I try to think about as follows:
a.  SOLICIT/REBIND must include this option because they are directly related to the RADIUS accept-access message;
b.  REQUEST must include this option because the server need the indication from it to assign the address/prefix;
c.  RENEW should include it if the server would not like to keep those attributes; or might not include it if the server keep the attributes for the client in the lease of the address/prefix;
d.  RELEASE might not need to include it, but the inclusion could help to release the attributes in the server if the server would like to keep them;
e.  DHCPv6-PD don't use DECLINE, CONFIRM; but in the case of pure DHCPv6 for address assignment to host, if the relay include this option, it could be harmless;
f.  INFORMATION-REQUEST is used for the case of non-address/prefix assignment to host, if the relay include this option, it also could be harmless;
In the end, I tend to keep the text right now. Your further opinion?

Tomek - 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.

Agreed. The text sounds redundant, but harmless. :-)

Tomek - 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.

Bernie mentioned in his comments @ http://www.ietf.org/mail-archive/web/dhcwg/current/msg13350.html . ERO might request the server to reply the OPTION_RADIUS, though I haven't figured out that use case yet. Maybe we need more discussion on it, but the above revision sounds harmless again?

Tomek - 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.

Any further suggested text on it? There is a text in section 9 as follows: 'The IETF expert review SHOULD include careful consideration of the security implications of allowing the relay agent to include the RADIUS attribute being considered for addition to this registry.'

Tomek - ...I support this document going forward.

I really appreciate the above Tomek's thorough review, though long comments always need long reply. :-)

Best Regards,
Leaf

-----Original Message-----
From: Tomek Mrugalski [mailto:[email-masked]] 
Sent: Saturday, December 01, 2012 1:27 AM
To: [email-masked]; Leaf yeh
Subject: Comments on draft-ietf-dhc-dhcpv6-radius-opt-05.txt

On 29.11.2012 13:13, [email-masked] wrote:
> 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.

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

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 10 Dec 2012 15:53:10 +0100

On 04.12.2012 12:45, Leaf yeh wrote:
>> Tomek - 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.
> 
> IPoE means IP over Ethernet, which is borrowed from Broadband Forum
> TR-177. I guess it is a well-known word and it means a well-known
> access model. It does 'represents the scenario when the access loop
> supports direct Ethernet encapsulation'. Per the description in BBF
> TR-177 & TR-187, IPoE and PPPoE are 2 typical network models. How
> about update the text to be 'Figure 1 shows the sequence of DHCPv6
> and RADIUS messages for IP over Ethernet (IPoE) access model, when
> the access loop adopts the direct Ethernet encapsulation' ?
It was just a simple comment about using an abbreviation that was not
explained before. Your proposal sounds good.

>> 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?
> When the access model changes, the message sequences in the Fig.1 of
> IPoE look differently with the Fig.2 of PPPoE.
My question was a bit more generic. I think that IPoE is a generic case
that many deployments will encounter (not just service provider
networks, but also e.g. campus networks with WiFi access points or
corporate networks), while PPPoE is something rather service provider
specific.

> The 1st sentence in section 3 has said that 'In these scenarios, the
> centralized DHCPv6 server is not co-located with the RADIUS
> server,...'
Yes, the text is clear. It was just a suggestion how to make the figure
clearer and less ambiguous. If you think that the text is sufficient, I
won't insist on this.

>> 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")?
> 
> Accepted. I will change the text to be 'SHOULD/SHOULD NOT' if you
> care. It seems to me the roughly same mechanism was introduced by
> section 3 of RFC6519, but we have DHCPv6 relay here. The text in
> section 3 of RFC6519 has 1x 'does not have' and 1x 'MUST'. Your
> further opinion?
Too long, didn't read :) Just use common sense and RFC2119
recommendations. 2119 is really short - just 2 pages.

> Appreciate your carefulness. I tend not to touch the word of
> 'stateful', but could make the clarification after Fig. 2 in section
> 3 as follows: 'If the authentication or the authorization through
> RADIUS passes, the NAS MUST store the RADIUS attributes received in
> the Access-Accept message from the RADIUS server during the whole
> session.' I regard this is the part of the RADIUS protocol.
Ok. You may add that radius state and exact retention policy is outside
of this document and just reference whatever document governs NAS behavior.

>> stateless option. See my suggestion about clarifying if this
>> RADIUS option may appear when relaying inf-request and other
>> messages.
> 
We do. Thanks.

>> 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.
> 
> Section 4 of RFC4014 used the word of 'SHOULD'. The option doesn't
> send 'every attribute', but one or more RADIUS attributes in the
> recommended list.
Ok, so it is perhaps something that slipped through during RFC4014 review.

>> 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.
> 
> In your example, the NAS gets the 'special prefix' in the attribute
> of Delegated-IPv6-Prefix (123) from the RADIUS server. Then the relay
> only need to convey the Delegated-IPv6-Prefix (123) to the server. I
> meant the relay don't need to convey 'User-Name (1)' through this
> option to the server, if it is regarded only for the RADIUS server.
You are thinking about your use cases. It's not about prefixes and
addresses only. What if I want someone with special Radius user-name to
get a different set of other DHCP options, special personal dns server
for my boss, dedicated NTP server for engineers in lab etc?

I'd like it to be a generic Radius option that happens to solve your
cases, but is flexible enough to cover others as well.

> OPTION_RADIUS, I try to think about as follows: a.  SOLICIT/REBIND
> must include this option because they are directly related to the
> RADIUS accept-access message; b.  REQUEST must include this option
> because the server need the indication from it to assign the
> address/prefix; c.  RENEW should include it if the server would not
> like to keep those attributes; or might not include it if the server
> keep the attributes for the client in the lease of the
> address/prefix; d.  RELEASE might not need to include it, but the
> inclusion could help to release the attributes in the server if the
> server would like to keep them; e.  DHCPv6-PD don't use DECLINE,
> CONFIRM; but in the case of pure DHCPv6 for address assignment to
> host, if the relay include this option, it could be harmless; f.
> INFORMATION-REQUEST is used for the case of non-address/prefix
> assignment to host, if the relay include this option, it also could
> be harmless; In the end, I tend to keep the text right now. Your
> further opinion?
Again, this mechanism should be generic and cover other cases than just
prefix delegation. I propose:
MUST during relaying SOLICIT, REQUEST and RENEW
MAY during relaying every other client message.

> Tomek - 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.
> 
> Bernie mentioned in his comments @
> http://www.ietf.org/mail-archive/web/dhcwg/current/msg13350.html .
> ERO might request the server to reply the OPTION_RADIUS, though I
> haven't figured out that use case yet. Maybe we need more discussion
> on it, but the above revision sounds harmless again?
Ok, good point. Let's keep the text as it is.

> Tomek - 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.
> 
> Any further suggested text on it? There is a text in section 9 as
> follows: 'The IETF expert review SHOULD include careful consideration
> of the security implications of allowing the relay agent to include
> the RADIUS attribute being considered for addition to this
> registry.'
Existing text is ok, but it is not sufficient and it talks about
different circumstances (what to do when someone tries to add a new
option to the registry). I'm talking about potential security problems
once the protocol is deployed. How about this one:

"Networks that deploy this mechanism may allow new attack vector against
DHCPv6 servers in case DHCPv6 relay is compromised. By forging Radius
options in relayed messages, the attacker can influence DHCPv6 server
assignment policy.". In simple words, if your Radius authentication is
completely secure and bullet proof, someone still can hijack your relay
and just include options that say "yeah, this user has authentication,
honest!" and the server will happily provision an unathenticated device.

Cheers,
Tomek

---

From: Leaf yeh <[email-masked]>
Date: Fri, 14 Dec 2012 07:59:24 +0000

> IPoE look differently with the Fig.2 of PPPoE.
Tomek - My question was a bit more generic. I think that IPoE is a generic case
that many deployments will encounter (not just service provider
networks, but also e.g. campus networks with WiFi access points or
corporate networks), while PPPoE is something rather service provider
specific.

PPP (oE) is always related to the AAA mechanism of RADIUS, and sounds a native feature (or function) of the Broadband Access Server, which is the key network component in the use cases defined in the draft.

Section 1.2 of RFC2865 has the definition of 'session', but it seems difficult to find the exact words on 'radius state' or 'retention policy' in this RFC.

> option to the server, if it is regarded only for the RADIUS server.
Tomek - You are thinking about your use cases. It's not about prefixes and

I tend to keep the scope of the draft for the use cases defined, and still can't get the border of your question on the real use case yet. 

> be harmless; In the end, I tend to keep the text right now. Your
Tomek - Again, this mechanism should be generic and cover other cases than just
prefix delegation. I propose:
MUST during relaying SOLICIT, REQUEST and RENEW
MAY during relaying every other client message.

As the appearance of the OPTION_RADIUS, how about the following text: ' According to the network scenarios described in section 3, the OPTION_RADIUS SHOULD appear in the RELAY-FORW (12) message relaying SOLICIT (1), REQUEST (3) and REBIND (6) from the DHCPv6 client, and MAY appear in the RELAY-FORW (12) relaying any other message from the    DHCPv6 client. ' ?

> the RADIUS attribute being considered for addition to this

Tomek - Existing text is ok, but it is not sufficient and it talks about

I would adopt the above text for 'Security Consideration' if you insist. How about the text to be: 'The mechanism described in this document may introduce new attack vector against the DHCPv6 server in case the DHCPv6 relay agent is compromised. By forging the RADIUS attributes contained in the OPTION_RADIUS of the RELAY-FORW (12) messages, the attacker may influence the parameter assignment on the DHCPv6 server for the DHCPv6 clients. But in the network scenarios described in the section 3, NAS could always be regarded as a trusted network component in the real deployment. ' ?

Best Regards,
Leaf

-----Original Message-----
From: Tomek Mrugalski [mailto:[email-masked]] 
Sent: Monday, December 10, 2012 10:53 PM
To: [email-masked]
Cc: Leaf yeh
Subject: Re: Comments on draft-ietf-dhc-dhcpv6-radius-opt-05.txt

We do. Thanks.

Cheers,
Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 14 Dec 2012 13:41:22 +0100

On 14.12.2012 08:59, Leaf yeh wrote:
>> 'stateful', but could make the clarification after Fig. 2 in
>> section 3 as follows: 'If the authentication or the authorization
>> through RADIUS passes, the NAS MUST store the RADIUS attributes
>> received in the Access-Accept message from the RADIUS server during
>> the whole session.' I regard this is the part of the RADIUS
>> protocol.
> Ok. You may add that radius state and exact retention policy is
> outside of this document and just reference whatever document governs
> NAS behavior.
> 
> Section 1.2 of RFC2865 has the definition of 'session', but it seems
> difficult to find the exact words on 'radius state' or 'retention
> policy' in this RFC.
Ok. So I think just saying that "how NAS manages the state is outside of
scope of this document" would be ok.

>> In your example, the NAS gets the 'special prefix' in the
>> attribute of Delegated-IPv6-Prefix (123) from the RADIUS server.
>> Then the relay only need to convey the Delegated-IPv6-Prefix (123)
>> to the server. I meant the relay don't need to convey 'User-Name
>> (1)' through this option to the server, if it is regarded only for
>> the RADIUS server.
> Tomek - You are thinking about your use cases. It's not about
> prefixes and addresses only. What if I want someone with special
> Radius user-name to get a different set of other DHCP options,
> special personal dns server for my boss, dedicated NTP server for
> engineers in lab etc? I'd like it to be a generic Radius option that
> happens to solve your cases, but is flexible enough to cover others
> as well.
> 
> I tend to keep the scope of the draft for the use cases defined, and
> still can't get the border of your question on the real use case yet.
Since nobody else joined the discussion, I suppose there's not much
desire for other cases. Keep the text as it is then.

> As the appearance of the OPTION_RADIUS, how about the following text:
> ' According to the network scenarios described in section 3, the
> OPTION_RADIUS SHOULD appear in the RELAY-FORW (12) message relaying
> SOLICIT (1), REQUEST (3) and REBIND (6) from the DHCPv6 client, and
> MAY appear in the RELAY-FORW (12) relaying any other message from the
> DHCPv6 client. ' ?
Sounds good. I'm not sure if you meant REBIND or RENEW, but I'm fine
with both.

> Tomek - Existing text is ok, but it is not sufficient and it talks
> about different circumstances (what to do when someone tries to add a
> new option to the registry). I'm talking about potential security
> problems once the protocol is deployed. How about this one: "Networks
> that deploy this mechanism may allow new attack vector against DHCPv6
> servers in case DHCPv6 relay is compromised. By forging Radius 
> options in relayed messages, the attacker can influence DHCPv6
> server assignment policy.". In simple words, if your Radius
> authentication is completely secure and bullet proof, someone still
> can hijack your relay and just include options that say "yeah, this
> user has authentication, honest!" and the server will happily
> provision an unathenticated device.
> 
> I would adopt the above text for 'Security Consideration' if you
> insist. How about the text to be: 'The mechanism described in this
> document may introduce new attack vector against the DHCPv6 server in
> case the DHCPv6 relay agent is compromised. By forging the RADIUS
> attributes contained in the OPTION_RADIUS of the RELAY-FORW (12)
> messages, the attacker may influence the parameter assignment on the
> DHCPv6 server for the DHCPv6 clients. But in the network scenarios
> described in the section 3, NAS could always be regarded as a trusted
> network component in the real deployment. ' ?
I don't have any experience with NAS, but my understanding is that if
someone manages to hijack your NAS you have bigger problems than just
influencing your DHCP server. But since this draft is about DHCP, it is
useful to mention that. Your proposed text is ok.

Ok, this addresses all my comments. Thank you.

Cheers,
Tomek