Re: REMINDER: Response to the review comments on draft-ietf-dhc-agentopt-radius-06.txt

[Paul Funk <paul@funk.com>]

I goofed. My apologies. Next time I'll wait 10 minutes before I
hit "Send".

The authors are correct in stating that "there is no standard for
encoding long relay agent option sub-options (the equivalent of
RFC 3396 for sub-options)", and in fact it would be necessary
to encode a long sub-option as well as a long outer DHCP
Relay option to overcome the 255 byte limitation.

However, it seems to me that this is an important enough problem
that a long sub-option mechanism should be defined. In a quick
read of RFC 3046, I didn't see that repeating a sub-option is
precluded.(though I won't guarantee I didn't miss it). If that's true,
the fragmentation of the RADIUS attributes sub-option could be
defined within this draft without violating any rules. Alternatively, a
separate draft for long sub-options (similar to RFC 3396) could be
proposed in conjunction with this draft.

I think eliminating the 255 byte limitation is necessary in order for
this mechanism to be robust.

Paul


--------- previous message ------------
Bernard,

The critical limitation of 255 bytes for a sequence of RADIUS
attributes is explained as capable of being managed within the
administrative domain. But this is begging the question. The
administrative domain may not be control of the length of the
user name or class attribute or VSAs, the NAS itself may
require attributes of a certain volume, etc. How a RADIUS
server is supposed to limit aggregate attribute size for the
purposes of this draft, in the face of variable length data, is an
exercise left for the reader. The result will be some percentage
of failures, and the backwash from this will fall on the RADIUS
server.

However, I have looked at RFC 3396 and it appears that there is
an existing mechanism to handle this problem. You simply encode
the entire DHCP Relay option as a "long option" according to that
RFC. A long option is simply a fragmentation of a payload longer
than 255 bytes into multiple options of the same type one after the
other. The receiver simple reassembles and treats it as a single
option with long payload.

In their response to comments, the authors stated that "there
is no standard for encoding long relay agent option sub-options
(the equivalent of RFC 3396 for sub-options)". But you don't encode
long sub-options, you encode the outer DHCP Relay option itself
as a long option.

If this is done, it becomes a workable protocol and my issues are
resolved.

Paul

At 04:59 PM 7/13/2004 -0700, Bernard Aboba wrote:
> Thanks, Greg.
>
> According to my records, comments are still required from Paul Funk and
> Ashwin Palekar.
>
> Paul, Ashwin -- can you look at Ralph's response and weigh in?
>
> On Tue, 13 Jul 2004, Greg Weber wrote:
>
> >
> >
> > I went through the -07 draft.  I believe the issues that I
> > raised are resolved or can otherwise be closed.
> >
> > Regarding the authorization data lifetime, the draft proposes
> > behavior that seems analogous to the use of the Class attribute
> > in service provider deployments that use separate servers for
> > authentication and accounting.  The authentication server may
> > return one or more Class attributes to the NAS without knowing
> > whether they are actually used by the accounting server to
> > which they are eventally sent; and the Class attributes are
> > cached for the life of the session.  So, I think it's reasonable
> > to say the RADIUS attributes suboption data is also cached for
> > the duration of the user session.
> >
> > Greg
> >
> > >
> > > Ralph Droms has posted suggested resolutions to the AAA-Doctors comments
> > > on draft-ietf-dhc-agentopt-radius-06.txt.  Earlier I sent out a 
> summary of
> > > the issues raised in the review.
> > >
> > > Please respond to this list whether the proposed resolutions are
> > > acceptable to you.  I will collect the feedback and send it to Ralph.
> > >
> > > -- Bernard

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