[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: HTTP digest and RADIUS; new version of the Sterman draft
> Alan DeKok writes...
> > > The technical arguments that I have heard (and advanced) against
> > > sub-types are that it changes the RADIUS architecture (simple TLV
> > > structures), requires changes to the RADIUS dictionary, and breaks
> > > backwards compatibility with a large deployed base of RADIUS
> > ... which we already know won't understand the new attributes.
> Yes, but they could by updating their dictionary file (or equivalent
> dictionary implementation). I guess that was the point of my admittedly
> imperfect analogy with SNMP -- data dictionary driven protocol parsing,
> as opposed to code driven parsing. I argue that adding sub-types means
> changing the parsing code.
Catching up on this discussion... Would the code changes you
mention be necessary for all RADIUS endpoints or only those
that wish to understand sub-typed attributes? I would think
that sub-typed data (as in Diameter) could be structured to
look like a regular attribute at the highest level. And at
that level these attributes would be ignored by endpoints
that don't have definitions for them. That would seem to
indicate that sub-typed data could be compatible with existing
devices, but code changes would be necessary to take advantage
of the new attributes. As to the code changes, I would imagine
that most RADIUS client/servers already have code to parse
structured values as many VSA values have structured data.
One advantage of formalizing sub-typed data might be to imposing
or strongly encouraging that same structured framework on VSAs.
I'm fearful of heading towards lots of different VSA structures,
e.g. IS-835 has at least a couple different VSA-specific ways
of sub-typing data.
> RADIUS implementations have been designed
> from day-one to deal with new attributes, in the standard single-layer
> TLV format.
> I do understand that a NAS or RADIUS server that actually wants to do
> something useful with the semantics of a new attribute will need added
> or changed code somewhere, even if not in the core RADIUS protocol
> > The only hard requirement I can see for backwards compatibility is
> > that old servers MUST be able to act as proxies for requests with new
> > attributes. We've seen this behaviour with EAP-Message, so we know it
> > works.
> I suppose I draw a distinction that not everyone will agree with. EAPOL
> frames are not RADIUS attributes in the classic sense of the definition.
> I see tunneling EAP in RADIUS as a natural thing to do. Many of the
> other proposed new attributes seem like any other RADIUS attribute to
> me, and thus I resist the notion of tunneling, or sub-typing.
> > If tagged attributes are sufficient, then I see no reason to add new
> > sub-types.
> That works for me. Let's see if it works for others.
> -- Dave
> to unsubscribe send a message to firstname.lastname@example.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.