(RADIATOR) Vendor specific attributes and sub-attributes.

[Hugh Irvine]

Hello Kiran -

You are quite correct in your understanding - the OSC-AVPAIR (and other 
similar vendor-specifics) is simply defined as a string. The string 
itself can contain anything at all. If the string is to contain 
multiple attribute= value pairs then it can be parsed as you describe. 
There are no "rules" or standards specified by the RFC's.

BTW - Cisco uses this construct extensively with their "cisco-avpair" 
VSA- see the Cisco web site for more information.

regards

Hugh


On 30 Jul 2004, at 02:24, Chandrashekar, Kiran wrote:

> Hello Hugh,
> Thanks for the reply. A follow-up question - Kindly help.
>
>> From your example, how will the remote side know what xxx, yyy and 
>> zzz are? By virtue of these values being Vendor-specific, can the 
>> Vendor describe the format according to his wishes? Are there any 
>> rules that govern how this data(OSC-AVPAIR = "xxx=1, yyy=2, zzz=3, 
>> .....") needs to be represented?
>
> Currently, I am stuck in trying to explain to the developer that as 
> far as the values within the string are comma separated and AV pairs, 
> he can always parse and split them as tokens based on the comma and 
> "=" parameters. I am not convinced that this is prescribed in the RFC 
> and the way to do it.
>
> The developer sticking to the RFC is demanding that values(of 
> OSC-AVPAIR) a.k.a sub-attributes should be in the TLV format. If the 
> attribute OSC-AVPAIR is a string, how can I enforce everything in the 
> string to be in the TLV format, this just doesn't seem possible. I am 
> totally confused.
>
> Thanks in advance,
>
>
>
> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: Tuesday, July 27, 2004 7:26 PM
> To: Chandrashekar, Kiran
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) Vendor specific attributes and sub-attributes.
>
>
> Hello Kiran -
>
> The usual way to do this is with an avpair.
>
> For example we have defined a number of vendor-specifics for OSC,
> including this one:
>
> VENDORATTR 9048 OSC-AVPAIR 0 string
>
> which can then contain anything you like
>
> Ie:
>
> 	AddToReply OSC-AVPAIR = "xxx=1, yyy=2, zzz=3, ....."
>
> most vendors use something similar.
>
> Note that you should not use the "standard" attribute numbers as you
> have shown below.
>
> regards
>
> Hugh
>
>
> On 28 Jul 2004, at 08:14, Chandrashekar, Kiran wrote:
>
>>
>>
>> Hello,
>>
>> I have a question regarding vendor-specific attributes - Can I define
>> ONE attribute which can contain sub-attributes?
>>
>> Currently, I have defined 7 attributes in the following order.
>>
>> ATTRIBUTE        XXX_ATTR1                28 string XXX
>>  ATTRIBUTE        XXX_ATTR2          29 string XXX
>>  ATTRIBUTE        XXX_ATTR3              30  integer XXX
>>  ATTRIBUTE        XXX_ATTR4            31 integer XXX
>>  ATTRIBUTE        XXX_ATTR5              32 integer XXX
>>  ATTRIBUTE        XXX_ATTR6                33 integer XXX
>>  ATTRIBUTE        XXX_ATTR7           34 integer XXX
>>
>> But, Can I define one VSA which will include all the above?
>>
>> How will the dictionary file look like then?
>>  What changes do I need to make to users logging into the file?
>>
>> Any help is appreciated.
>>  Thanks,
>>  Kiran Chandrashekar
>>  ThinkEngine Networks, Inc.
>>  100 Nickerson Road
>>  Marlboro, MA  01752
>>  Direct:  508-597-0461
>>
>>
>
> NB: have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
>
> -- 
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> -
> CATool: Private Certificate Authority for Unix and Unix-like systems.
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.