[RADIATOR] dictionary entries for Ascend conflict with IANA assigned ones

[Heikki Vatiainen]

On 06/06/2011 07:27 PM, Bruno Tiago Rodrigues wrote:

> The standard radiator dictionary file specifies at least a pair of
> invalid entries sharing the same ID.
> Apparently, Ascend defines a set of attributes on the global  (IANA
> assigned) range.
> 
> ATTRIBUTE    X-Ascend-FCP-Parameter            119    string -
> conflicts with Digest-Domain
> ATTRIBUTE    X-Ascend-Modem-PortNo            120    integer -
> conflicts with Digest-Stale
> ATTRIBUTE    X-Ascend-Modem-SlotNo            121    integer -
> conflicts with Digest-HA1
> ATTRIBUTE    X-Ascend-Modem-ShelfNo            122    integer -
> conflicts with SIP-AOR
> ATTRIBUTE    X-Ascend-Call-Attempt-Limit        123    integer -
> conflicts with Delegated-IPv6-Prefix
> 
> (Possibly more. See
> http://www.iana.org/assignments/radius-types/radius-types.xml for
> reference)
> 
> These entries show up on the dictionary.ascend file (which makes
> sense, some people might still be using equipment with the "invalid
> ID" Ascend attributes) but for the rest of the crowd deploying IPv6
> (for instance), it takes a few hits at the standard dictionary file to
> comment out the "old" lines, as these entries still show up there.
> 
> I was wondering if this could be fixed (or at least documented) on the
> next releases.

I'll check about adding these to Radiators dictionary. If the attributes
from IANA are added after the conflicting old Ascend attributes, then
Radiator will treat e.g., incoming attribute 119 as Digest-Domain.

About attributes 126-132 that Alan mentioned, those are already in
dictionary. The dictionary has the old Ascend attributes first followed
later by IANA versions of 126-132.

As a result one can this:
./radpwtst -trace 4 -noacct  Operator-Name=4
or this
./radpwtst -trace 4 -noacct  Ascend-Route-Preference=4

but in both cases Radiator sees attribute 126 as Operator-Name with
results like this respectively:

        Operator-Name = "4"
        Operator-Name = "<0><0><0><4>"

Since Operator-Name is a string and Ascend-Route-Perference is an
integer, radpwtst packs a string or int into outgoing request. When
Radiator receives the attribute it always treats it as a string.

So adding the IANA attributes 119-123 after the Ascend attributes would
bring them available for Radiator and for example, radpwtst could be
used with old Ascend and the current IANA attributes. It might also be
possible to remove the old Ascend attributes completely, but I'm not
sure if that changes anything as long as the current IANA attributes are
defined in the dictionary too.

I'll do some research about this.

Thanks!

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.