Re: FW: HTTP digest and RADIUS; new version of the Sterman draft

[Greg Weber <gdweber@cisco.com>]

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

Greg

> 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
> engine.
> 
> >   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 radiusext-request@ops.ietf.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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>