[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Questions on RADIUS Extended attributes



Bernard Aboba <mailto:bernard_aboba@hotmail.com> supposedly scribbled:

>> I know that a couple of people stated that preference on the list
>> recently, but without any technical justification.
> 
> I think there may have been some concern about compatibility with
> existing RADIUS servers, since the format proposed in the Lior & Li
> draft utilized a larger Extended-Type field (32 bits) than was
> suggested for the VSA format in RFC 2865.

Yes, that's actually what I'm questioning the need for...
   
> 
>> Is it really necessary to do more than double the number of standard
>> attributes?  That is what the >VSA approach would do, without
>> requiring code changes...
> 
> I think the implicit assumption here is that the VSA approach
> (Vendor-Id of 0) would utilize the VSA format described in RFC 2865
> (single octet Type 
> field).   

Yes, sorry, I should have been more explicit.

> However, the Lior & Li proposal was for a larger
> Extended-Type 
> space, and I presume that this would require code changes.
> 
>> In combination with the tagging scheme (or something very similar)
>> you mentioned in a recent >message, the "VSA Zero" approach solves
>> this problem, as well.
> 
> RFC 2865 states that more than one vendor-specific attribute can be
> included within a RADIUS attribute of Type 26.  However, I don't
> think it describes how vendor-specific attributes can be split across
> RADIUS attributes of Type 26.  One way to address this is via a
> tagging scheme.  I think the question is whether we'd want to
> *require* tags in each Extended attribute, or not. 

I'd say yes -- the semantic difficulties w/the tagging scheme in RFC 2868 are I think in some part due to the false economy of trying to make the Tag field "disappear" if unused.  Things would have been much had the Tag field been a real field in the attributes.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
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/>