Re: Pls review/comment on: draft-ietf-dhc-agentopt-radius-06.txt

[Paul Funk <paul@funk.com>]

Yet another approach would be to have a RADIUS attribute
that encapsulated a DHCP option. Then, the RADIUS server
could be configured to allow arbitrary options to be added to
a DHCP request. They could be vendor-specific as well.

Paul

----------------------

Bert,

I read the draft quickly, but it appears that the all the RADIUS
attributes are encoded into a single DHCP option. Since that
is limited to 255 bytes, I'm not sure how useful or reliable this
will be. RADIUS servers cannot be configured to limit the
total length of their attributes to 255 bytes and remain usable
for their main purpose, which is authentication and authorization.

I'm not sure if it is legal in DHCP to repeat an option. If it is,
RADIUS attributes could be encoded one per option.

An alternate approach would be to configure the RADIUS server
as to which attributes should be forwarded to the DHCP server.
There might be a new or VS attribute that would be useful in
some application to forward to the DHCP server, and it is always
more convenient to configure such things in the RADIUS server
rather than in the NAS. The NAS is best left to blindly do what
it is told rather than to make decisions like which attribute to
forward as a DHCP option.

The basic problem is the sheer volume of information produced.
In such cases, maybe the best thing is to just to provide a method
of indirection, like a policy name or something. For example, to
configure a packet filter, you can send the name of the filter rather
than a list of rules. So maybe what's really required is a RADIUS
"DHCP-Policy" attribute, jointly configured at RADIUS server and
DHCP server, and the NAS simply forwards between the two.

Paul



At 06:13 PM 4/28/2004 +0200, Wijnen, Bert (Bert) wrote:
> I am very sorry to be so late.
>
> But this doc is on tomorrows (Thursday 29th) IESG agenda.
> So if you can review and comment.. PLEASE DO.
>
> If you do a quick scan and see a need to take a closer look,
> pls let me know. I can take a DEFER in that case which gives
> us some extra time.
>
> Thanks,
> Bert

Paul Funk
Funk Software, Inc.
617 497-6339
paul@funk.com