Subject: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

From: Jouni Korhonen <[email-masked]>
Date: Thu, 4 Apr 2013 15:13:29 +0300

Folks,

draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC
in DHC WG. RADEXT WG is solicited for review. We can provide
input as part of the IETF LC once it is started.  Remember to
CC the RADEXT so we can keep  track of the (possible) comments
better.

- Jouni & Mauricio

---

From: Alan DeKok <[email-masked]>
Date: Thu, 04 Apr 2013 09:08:29 -0400

> CC the RADEXT so we can keep  track of the (possible) comments

  A quick review:

4.  DHCPv6 RADIUS option

    option-len       Length of the option-data in octets

Q: Can it encode more than 256 octets of RADIUS attributes?  If so, what
happens then?

   ... Only the attributes listed in the IANA Registry of 'RADIUS
   attributes permitted in DHCPv6 RADIUS option' SHOULD be included in
   the OPTION_RADIUS.

 That should be a MUST.  There's no sense in permitting non-RADIUS
traffic in this option.

8.  Security Considerations

   Known security vulnerabilities of the DHCPv6 and RADIUS protocol MAY

  Using "MAY" here is probably wrong.  It should be "may".

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 5 Apr 2013 00:54:33 +0800

Alan - option-len       Length of the option-data in octets
Q: Can it encode more than 256 octets of RADIUS attributes?  If so, what
happens then?
---

The 'option-len' is 2-octet field. It permit the length of 'option-data' is
larger than 256, when the OPTION_RADIUS includes a number of RADIUS
attributes. I think the RADIUS attribute here can also be the attribute of
Long_Extended_Type newly defined in draft-ietf-radext-radius-extensions-13.

Alan - ... Only the attributes listed in the IANA Registry of 'RADIUS
   attributes permitted in DHCPv6 RADIUS option' SHOULD be included in
   the OPTION_RADIUS.
 That should be a MUST.  There's no sense in permitting non-RADIUS traffic
in this option.
---

Do you want the text to be 'Only the attributes listed in ....MUST be
included in ...."? How about turn that 'SHOULD' to be 'should' ?

Alan - 8.  Security Considerations
   Known security vulnerabilities of the DHCPv6 and RADIUS protocol MAY
  Using "MAY" here is probably wrong.  It should be "may".
----

Accepted. That 'MAY' will update to be 'may'.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alan DeKok
Sent: Thursday, April 04, 2013 9:08 PM
To: Jouni Korhonen
Cc: [email-masked]; [email-masked]
Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

Jouni Korhonen wrote:
> draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC in DHC 
> WG. RADEXT WG is solicited for review. We can provide input as part of 
> the IETF LC once it is started.  Remember to CC the RADEXT so we can 
> keep  track of the (possible) comments better.

  A quick review:

4.  DHCPv6 RADIUS option

 That should be a MUST.  There's no sense in permitting non-RADIUS traffic
in this option.

  Using "MAY" here is probably wrong.  It should be "may".
_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 4 Apr 2013 10:12:13 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alan DeKok
> Sent: Thursday, April 04, 2013 6:08 AM
> To: Jouni Korhonen
in
> this option.

Alan, I have not looked at the registry in question yet, however should
there be the ability to send vender defined traffic?

Jim

---

From: Alan DeKok <[email-masked]>
Date: Thu, 04 Apr 2013 13:42:38 -0400

> there be the ability to send vender defined traffic?

  That's what VSAs are for.

  If the option is defined as transporting RADIUS, then it (IMHO)
transports RADIUS.  Anything else is wrong.

  Alan DeKok.

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 5 Apr 2013 01:49:01 +0800

Jim - ...however should there be the ability to send vender defined traffic?

The VSA (26) has recommended in the proposed IANA Registry of 'RADIUS
attributes permitted in DHCPv6 RADIUS option'. (Section 4.1)
Do you want more?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jim Schaad
Sent: Friday, April 05, 2013 1:12 AM
To: 'Alan DeKok'; 'Jouni Korhonen'
Cc: [email-masked]; [email-masked]
Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alan DeKok
> > WG. RADEXT WG is solicited for review. We can provide input as part 
> > of the IETF LC once it is started.  Remember to CC the RADEXT so we 
> > can keep  track of the (possible) comments better.
> 
>   A quick review:
> 
> 4.  DHCPv6 RADIUS option
> 
> Q: Can it encode more than 256 octets of RADIUS attributes?  If so, 
> what happens then?
> 
> 
> traffic
in

Jim

---

From: Alan DeKok <[email-masked]>
Date: Thu, 04 Apr 2013 13:49:44 -0400

Leaf Yeh wrote:

> attributes.

  Ah, I didn't see that.  It's OK, then.

> I think the RADIUS attribute here can also be the attribute of

  Sure... or you may want to limit the number of allowed attributes.

> included in ...."? How about turn that 'SHOULD' to be 'should' ?

  I'd say:

    This option MUST carry RADIUS attributes listed in the IANA Registry
of 'RADIUS attributes permitted in DHCPv6 RADIUS option'.

  Alan DeKok.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Apr 2013 17:59:15 +0000

> of 'RADIUS attributes permitted in DHCPv6 RADIUS option'.

I don't think that sentence means what you think it means.   This would require that these options be sent even if no values for them were configured on the RADIUS server.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 4 Apr 2013 11:44:00 -0700 (Pacific Daylight Time)

On Thu, 4 Apr 2013, Jouni Korhonen wrote:

> draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC in DHC WG. 
> RADEXT WG is solicited for review. We can provide input as part of the 
> IETF LC once it is started.  Remember to CC the RADEXT so we can keep 
> track of the (possible) comments better.

I like this scheme.  Just have two questions.

With the DHCPv6 relay forwarding should relays forward attributes it does 
not know about to server?  From my read (section 5) it seems to say 
attributes are forwarded if the relay validates value which seems to imply 
it can't forward attributes it does not know about?

The DHCP analogue (RFC 4014 sec 4) lists other attributes just wondering 
what is different here that makes the attribute lists different ...IPv6 
specific company excluded of course.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 04 Apr 2013 16:44:25 -0400

> I don't think that sentence means what you think it means.   This would require that these options be sent even if no values for them were configured on the RADIUS server.

  It doesn't say the option MUST be present.

  It doesn't say the option MUST carry ALL of the RADIUS attributes.

  It tries to say if you choose to use the option, its contents MUST be
RADIUS attributes, and nothing else.

  Alan DeKok.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 4 Apr 2013 13:48:23 -0700

in
> this option.

The SHOULD looks better if you are thinking of the upgrade path.  That is
what happens to an old implementation if a new item is added to the registry
and it starts receiving it.  Should it be ignored, passed on or what?

I would agree that it makes sense to say that they MUST be only those items
in the registry, but text should be included to deal with items which are
not in the registry (or are not known to be in the registry).

Jim

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Apr 2013 20:49:17 +0000

> RADIUS attributes, and nothing else.

While it can definitely be read that way, it doesn't exclude other readings.   To do that, perhaps:

	This option MUST NOT carry RADIUS attributes not listed in the IANA Registry
	of 'RADIUS attributes permitted in DHCPv6 RADIUS option'.

When we discussed this in the DHC working group, there was some controversy as to whether we need to even have such a restriction; I take it that you agree that there should be such a restriction?

---

From: Alan DeKok <[email-masked]>
Date: Thu, 04 Apr 2013 16:57:59 -0400

> 	of 'RADIUS attributes permitted in DHCPv6 RADIUS option'.

  Positive statements are usually clearer to understand.

> When we discussed this in the DHC working group, there was some controversy as to whether we need to even have such a restriction; I take it that you agree that there should be such a restriction?

  The intention is for the option to carry RADIUS attributes.  Making
that a requirement rather than a suggestion is a good idea.

  Alan DeKok.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Apr 2013 21:04:01 +0000

>  Positive statements are usually clearer to understand.

Yes, and when I read your statement, I understood it to mean the exact opposite of what you intended.   Easier to understand doesn't help if the statement is ambiguous.

> that a requirement rather than a suggestion is a good idea.

This isn't what the text says.   It says that the option must only carry a subset of RADIUS attributes; those listed in a special registry.

If you don't like the double negative, here's a precise way to say it that doesn't contain a double negative:

	This option MUST NOT carry any RADIUS attribute unless it is listed in the
	IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'.

But what the text that means what you said in the second quote above would read like this:

	This option MUST NOT carry any RADIUS attribute unless it is listed in the
	IANA Registry Radius Types registry in the section titled 'Radius Attribute Types'.

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 5 Apr 2013 10:19:36 +0300

> 	IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'.

I don't think this is any improvement over the text Alan provided originally.
My suggestion would be:

   The option-data of OPTION_RADIUS is a list of one or more RADIUS
   attributes received in the Access-Accept message from the RADIUS
   server. The OPTION_RADIUS can only contain RADIUS attributes
   listed in the IANA Registry of 'RADIUS attributes permitted in
   DHCPv6 RADIUS option'.

The next question I have is what happens when a relay includes an attribute
that the server does not understand or is not listed in the registry? There
is no versioning thus it is possible that relay and server have a different
understanding what the IANA registry is. Now the text in Section 6 only
addresses the case where the server does not understand the DHCP option.

- Jouni

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

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 5 Apr 2013 18:15:01 +0800

Peter - With the DHCPv6 relay forwarding should relays forward attributes it
does not know about to server?  From my read (section 5) it seems to say
attributes are forwarded if the relay validates value which seems to imply
it can't forward attributes it does not know about?

Good question. I think the point here is the DHCPv6 relay only forward those
valid attribute in the registry of 'RADIUS attributes permitted in DHCPv6
RADIUS option'. If the DHCPv6 server supports OPTION_RADIUS defined here, it
should know all the attributes received from the relay. If the DHCPv6 server
still does not know the attributes in OPTION_RADIUS, the server just ignore
those attributes per the Postel's Law.

Peter - The DHCP analogue (RFC 4014 sec 4) lists other attributes just
wondering what is different here that makes the attribute lists different
...IPv6 specific company excluded of course.

I guess you are talking about the following attributes (in the table of the
section 4 in RFC 4014):
           1   User-Name (RFC 2865 [3])
           6   Service-Type (RFC 2865)
          27   Session-Timeout (RFC 2865)
I still have not got the points (or understood the use case) for:
a. User-Name : why the User-Name of AAA (or RADIUS) will be necessary to
forward the DHCPv6 server; the standard DHCPv6 server sounds never use it
before;
b. Service-Type : what kind of service-type of AAA (or RADIUS,
http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-4
) will be necessary to forward the DHCPv6 server; 
c. Session-Timeout : I think the NAS (DHCPv6 relay + RADIUS client) can be
the 1st control point of trusted network , it can decide whether to forward
the DHCPv6 messages from the client to the server. After the session is
timeout, it just stop forward the DHCPv6 messages from the client to the
server. This RADIUS attribute also sounds not necessary to forward to the
DHCPv6 server. Right?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Deacon
Sent: Friday, April 05, 2013 2:44 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

regards,
Peter

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Apr 2013 11:42:58 +0000

>   listed in the IANA Registry of 'RADIUS attributes permitted in

So you took out the normative language, right?   Was that intentional?

> addresses the case where the server does not understand the DHCP option.

Good question.   I think the right answer is that that RADIUS attribute is silently ignored, because, as you say, the server might not be up to date.

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 5 Apr 2013 15:50:36 +0300

> So you took out the normative language, right?   Was that intentional?

That was intentional. If that is a concern one can always change the
"can only" to "MUST". That works too, since the previous sentence
already points out that the option contains one or more attributes,
not all.

> Good question.   I think the right answer is that that RADIUS attribute is silently ignored, because, as you say, the server might not be up to date.

Blindly dropping an attribute might not work in all cases. For example, in
some cases the server might not then be able to provide all information
the relay needs.. That is more of a DHCP specification issue but what I
would like to see in this I-D is some text pointing out that the server
and the relay may have a different idea of the registry and the protocol
design need to take that into account.

- Jouni

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Apr 2013 13:12:27 +0000

On Apr 5, 2013, at 8:50 AM, Jouni Korhonen <[email-masked]> wrote:
> the relay needs..

Well, I did say "silently ignored," not "dropped," but yeah.   If the server doesn't support that attribute, it's not going to have any effect anyway.   It seems like silently ignoring it is better than dropping the whole message, although I suppose you could argue the opposite, since a misconfiguration of this sort is probably something the administrator wants to fix immediately, not discover by accident years later.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Apr 2013 14:27:52 +0000

On Apr 5, 2013, at 10:16 AM, Tomek Mrugalski <[email-masked]> wrote:
> "Server MAY ignore received RADIUS attributes that it does not support."
> seems like a reasonable text here. Some implementors will ignore unknown
> attribute, some may produce a warning and some my try to handle it in a
> generic way.

Generally speaking, this sort of language is a recipe for attack.   I think the draft should just say that the administrator should be able to update the list of acceptable options.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 05 Apr 2013 10:28:28 -0400

> Generally speaking, this sort of language is a recipe for attack.   I think the draft should just say that the administrator should be able to update the list of acceptable options.

  That's probably best.

---

From: Peter Deacon <[email-masked]>
Date: Fri, 5 Apr 2013 09:11:31 -0700 (Pacific Daylight Time)

> Good question. I think the point here is the DHCPv6 relay only forward 
> those valid attribute in the registry of 'RADIUS attributes permitted in 
> DHCPv6 RADIUS option'. If the DHCPv6 server supports OPTION_RADIUS 
> defined here, it should know all the attributes received from the relay. 
> If the DHCPv6 server still does not know the attributes in 
> OPTION_RADIUS, the server just ignore those attributes per the Postel's 
> Law.

Hi Leaf,

Ok, my only concern here is relays tend to be "dumb" and outnumber DHCPv6 
servers in number and vendors involved.  It might be difficult to ever add 
new attributes in production as you would have to touch all relays to 
allow a new attribute to pass.  My guess VSAs would likely end up filling 
any gaps anyway.

> server. This RADIUS attribute also sounds not necessary to forward to the

Yes, I can't think of much either.

User-Name might be used to correlate any user specific settings stored in 
DHCP server or just logging purposes to understand end user associated 
with DHCP queries.

regards,
Peter

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Apr 2013 16:18:03 +0000

On Apr 5, 2013, at 12:11 PM, Peter Deacon <[email-masked]> wrote:
> Ok, my only concern here is relays tend to be "dumb" and outnumber DHCPv6 servers in number and vendors involved.  It might be difficult to ever add new attributes in production as you would have to touch all relays to allow a new attribute to pass.  My guess VSAs would likely end up filling any gaps anyway.

What's a VSA?   Should the document specify that the list of attributes to forward be customizable by the administrator?

I think the main purpose that the list of options not to forward serves is to have a default setting, and to exclude on a protocol specification level the use of options that we don't specifically intend be used; if an administrator configures some option that's not on the list, I think that's harmless.

---

From: Peter Deacon <[email-masked]>
Date: Fri, 5 Apr 2013 11:25:14 -0700 (Pacific Daylight Time)

> What's a VSA?  Should the document specify that the list of attributes 
> to forward be customizable by the administrator?

Hi Ted Lemon,

The configuration options sound good.

VSA = Vendor Specific Attribute (Vendor-Specific in table sec 4.1)

regards,
Peter

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 05 Apr 2013 16:16:39 +0200

On 05.04.2013 15:12, Ted Lemon wrote:
>> Blindly dropping an attribute might not work in all cases. For
>> example, in some cases the server might not then be able to provide
>> all information the relay needs..
> 
> Well, I did say "silently ignored," not "dropped," but yeah.   If the
> server doesn't support that attribute, it's not going to have any
> effect anyway.   It seems like silently ignoring it is better than
> dropping the whole message, although I suppose you could argue the
> opposite, since a misconfiguration of this sort is probably something
> the administrator wants to fix immediately, not discover by accident
> years later.
Anyway, dropping the whole message is definitely too radical here. We
have 3 options when server receives an unknown attribute:
a) ignore just the unknown attribute
b) ignore the whole radius option
c) ignore the whole message

I think we have an agreement that a) is the way to go. At least that's
what I strongly recommend.

Also, depending on server implementation, it is quite likely that the
server will parse unknown attributes and handle them in some generic
way, e.g. hex string. This is what some implementations do with unknown
DHCPv6 options and I imagine similar approach can be taken with RADIUS
attributes. Of course, such a behaviour is strictly implementation
specific, so there's no need to put anything about it in the spec.
So whether the attribute is "unknown" or not may be a bit blurry
definition sometimes.

Tomek

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 9 Apr 2013 01:31:36 +0800

Tomek - "Server MAY ignore received RADIUS attributes that it does not
support."

The draft (ver.-11) will have no further update on this point. OK?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alan DeKok
Sent: Friday, April 05, 2013 10:28 PM
To: Ted Lemon
Cc: dhcwg; <[email-masked]>
Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

Ted Lemon wrote:
> Generally speaking, this sort of language is a recipe for attack.   I
think the draft should just say that the administrator should be able to
update the list of acceptable options.

  That's probably best.

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 9 Apr 2013 01:31:36 +0800

Jouni - If that is a concern one can always change the "can only" to "MUST".

The draft (ver.-11) will take this point.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jouni Korhonen
Sent: Friday, April 05, 2013 8:51 PM
To: Ted Lemon
Cc: <[email-masked]>; dhcwg; Alan DeKok
Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

On Apr 5, 2013, at 2:42 PM, Ted Lemon <[email-masked]> wrote:

>> server. The OPTION_RADIUS can only contain RADIUS attributes  listed 
>> in the IANA Registry of 'RADIUS attributes permitted in
>>  DHCPv6 RADIUS option'.
> 

That was intentional. If that is a concern one can always change the "can
only" to "MUST". That works too, since the previous sentence already points
out that the option contains one or more attributes, not all.

>> The next question I have is what happens when a relay includes an 
>> attribute that the server does not understand or is not listed in the 
>> registry? There is no versioning thus it is possible that relay and 
>> server have a different understanding what the IANA registry is. Now 
>> the text in Section 6 only addresses the case where the server does not
understand the DHCP option.
> 
> Good question.   I think the right answer is that that RADIUS attribute is
silently ignored, because, as you say, the server might not be up to date.

Blindly dropping an attribute might not work in all cases. For example, in
some cases the server might not then be able to provide all information the
relay needs.. That is more of a DHCP specification issue but what I would
like to see in this I-D is some text pointing out that the server and the
relay may have a different idea of the registry and the protocol design need
to take that into account.

- Jouni