RADIUS iRule to insert vendor attributes

Hi Paul;

 

 

Some thoughts:

 

 

What happens when you try to insert your new value? I presume you are doing more than just appending a space to the end of attribute 26?

 

Are there any error logs or other clues?

 

Is the resulting packet too large for a single UDP packet?

 

 

regards, Sam

Hi Sam,

 

 

When you simply insert a new AVP it gets marked as bogus, and outside the vendor attribute area.

 

I suspect that is mainly because it is simply appended to the end of the packet and not after the last VSA.

 

 

The other issue is that i havent managed to define what the Vendor code and VSA attr are in any meaningful way.

 

 

I suspect with looking at raw packets the only way to do this will be with a UDP::payload replace.

 

 

There are a few examples of this but nothing with the depth that i will need, i will need to take the existing payload, insert the new VSA and then append the rest of the packet, then do the respond.

 

 

I am sure its possible i just need some pointers.

Hi Paul,

 

 

it is possible. however, current Radius iRule does not support inner attribute inside vendor-specific AVP. here is what you can try.

 

it might be easier to create new avp 26 and insert using radius iRule or using UDP::payload iRule.

 

 

example (not test)

 

 

create new vendor-specific (let use 3GPP as an example)

 

set vendor-id 10415

 

set vendor-type 1

 

set vendor-len 10

 

set vendor-str "12345678"

 

set attr [binary format Icca8 $vendor-id $vendor-type $vendor-len $vendor-str]

 

RADIUS::avp insert 26 $attr

 

 

alternatively, you can do this all in binary format

 

set type 26

 

set len 16

 

set vendor-id 10415

 

set vendor-type 1

 

set vendor-len 10

 

set vendor-str "12345678"

 

set attr2 [binary format ccIcca8 $type $len $vendor-id $vendor-type $vendor-len $vendor-str]

 

UDP::payload replace [UDP::payload length] 0 $attr2

 

 

if you want to append additional data to existing vendor-specific attribute, you can use same concept by reading existing AVP 26 to variable, formating data using binary format, appending new data to the variable and use RADIUS iRule to replace avp 26 with new value of variable.

 

 

note that current RADIUS iRule does not re-calculate Authenticator, if RADIUS client or server is strictly check for it, you may need to adjust the authenticator. it can be done by iRule. I can give you example if you need it.

 

 

Nat

Hi Nat,

 

 

Firstly, thanks for this...

 

I may need to do the authenticator, so an example would be useful.

 

I dont need to modify any existing VSA's just add new ones, one will be a calculated field and the other 2 are static.

 

 

They are Alcatel related:

 

 

Alc-Subsc-ID-Str

 

Alc-SLA-Prof-Str

 

Alc-Subsc-Prof-Str

 

 

The example above makes a lot of sense thanks for this.

here is how to recalculate authenticator.

 

note that iRule needs to know radius secret.

 

 

this is for Radius request.

 

for radius response, you need to save request's authenticator in variable and use that instead of "zero" when re-calculate authenticator.

 

 

     after all RADIUS::avp insert command

    set secret "secret"
    binary scan [UDP::payload] a1a1a2a16a* code id len auth attrs

     if you didn't use Radius iRule to insert new attribute, length may need to be recalculated
     you could probably do something like (assume radius packet contains no padding byte)
     set len [binary format S [UDP::payload length]]
    
     per RFC (don't remember which one 🙂 )
     Code + Identifier + Length + 16 zero octets + request attributes + shared secret
    set zero "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
    set newauth [md5 "${code}${id}${len}${zero}${attrs}${secret}"]
    
    UDP::payload replace 4 16 $newauth