VSA id's higer than 255

[Michael Lecuyer]

Ascend (as Lucent) has been introducing tags with values higher than 256 
in the VSA's for a while (first message I saw where the problem of long 
tags was mentioned was from January 2004).  An example from their 
dictionary shows:

ATTRIBUTE       Ascend-MOH-Timeout              261     integer

The format for the long tag VSA is the same as the standard 
Vendor-Specific attribute (8 bit tag, 8 bit length) but the 
sub-attribute tag field has been expanded to 16 bits. The sub-attribute 
length field remains 8 bits.

All vendor specific attributes are coded using 16-bit attribute type in 
network byte order and Lucent-Vendor-Id (4846) as Vendor-Id.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Attr Type     |   Length      |           Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Vendor-Id (cont)          |         Vendor Type(16-bit)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vendor Length |  Vendor-value......
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

I believe the support for long Vendor-Specific tags was discussed here 
in the past with limited interest in support.

It seems that this is on a NAS by NAS basis and only some of the VSA's 
are using the 16 bit tags. The solution seems to be to indicate that 
long tags are used by this NAS for particular vendors. Something like:

192.168.1.1 ... VendorLongTags=Ascend
- indicating that Ascend VSA's use long tags and all other VSA's like 
Cisco) would be short. Ascend / Lucent VSA's do not always use long tag 
VSAs.

This introduction of long tags is a real wart for every RADIUS server. 
There are probably other ways to have avoided 16 bit tags. Naturally the 
offender is too big to ignore and arbitrarily forced the issue. Remember 
that in the past Ascend (pre-Lucent) grabbed unassigned RADIUS 
attributes (from 119 to 255) without thinking there might be a problem 
with that either.

Alan DeKok wrote:
> Fawaz Qamhawi <fawazq at eim.ae> wrote:
>>Any simple solution for that ?
> 
> 
>   How are the attributes supposed to be encoded in the packet?  The
> normal VSA's use one byte to represent vendor attributes.  Since 287
> won't fit into ne byte, something else has to be done here.
> 
>   Alan DeKok.
> 
> - 
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> 
>