Length limitation of data type 'abinary' causes error "Hex data is too large for ascend filter"

[user018277]

Message

Attribute X-Ascend-Data-Filter(242) has the data type 'abinary' in the dictionary file dictionary.ascend.illegal:
ATTRIBUTE X-Ascend-Data-Filter 242 abinary
We have to change the data type of this attr into 'octets' on FreeRADIUS server, in order to avoid errors during filter processing:
ATTRIBUTE X-Ascend-Data-Filter 242 octets
The error message in FreeRADIUS, if the data type of attr 242 remains 'abinary':
"ERROR: Failed to create pair - Hex data is too large for ascend filter".
After the data type of attr 242 was changed into 'octets' (arbitrary binary data), no errors occur in FR and filter processing works normally.
Attribute 242 is used as IPv4/IPv6 filter attribute in many NAS types and by many ISPs. Could you please change the data type of attr 242 from 'abinary' into 'octets' in all new FR distributions?

[alandekok]

Changing the data type means that millions of existing systems will break. That's not an option.

Perhaps you could explain what "octets" data you're trying to add, and why it's longer than the default abinary type allows. Also explain what NAS equipment needs this. And if you can, point to any documentation for the NAS abinary type.

[user018277]

Cisco claims the abinary data type can be till 254 octets in length (range 0-254 octets).
https://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4.1/user/A_RADAtr.html
"
Ascend Dictionary of RADIUS AV Pairs

ACS supports the Ascend RADIUS AV pairs. Table C-9 contains Ascend RADIUS dictionary translations for parsing requests and generating responses. All transactions comprise AV pairs. The value of each attribute is specified as:

• string—0-253 octets.
• abinary—0-254 octets.
• ipaddr—4 octets in network byte order.
• integer—32-bit value in big endian order (high byte first).
• call filter—Defines a call filter for the profile.
"

However, the mentioned data length error "ERROR: Failed to create pair - Hex data is too large for ascend filter" steady occurs in FR server already at 48 octets length of the abinary data (IPv6 filer rules) in AVP X-Ascend-Data-Filter(242).

IPv4 filter rule of data length 24 octets in AVP X-Ascend-Data-Filter(242): no error occurs (OK).
IPv6 filter rule of data length 48 octets in AVP X-Ascend-Data-Filter(242): the mentioned length limitation error for abinary data always occurs!

Please note, that triggering length limitation error "Hex data is too large for ascend filter" at only 48 octets of IPv6 filter rule is a clear BUG that should be fixed in FR distribution, Changing the data type of X-Ascend-Data-Filter(242) from 'abinary' fo 'octets' in the dictionary is only a workaround which works for IPx filter, but not a real fix.

[user018277]

I assume that such a length limitation of the abinary data type is transparent for old ipv4 filters (24 octets), since ipv6 addresses and filters were not in use at that time. Nowadays, when ipv6 addresses and filters are widely in use, the old length restriction is critical as it already occurs at 48 octets of abinary data (ipv6 filter).

[alandekok]

Do you have an example of the binary data you're trying to add, as I asked? How are we expected to debug / test the issue if we don't have any test data?

Do you have a reference for the abinary format for IPv6 addresses? If you look at src/lib/filters.c, you'll see that there are no references to IPv6. This limitation explains why the server doesn't support IPv6 filters.

It's nice to submit bug reports. But it's better to give enough information, and useful information, which lets us fix the issue.

[user018277]

Here is the format used for ipv4/ipv6 filter rules in attribute X-Ascend-Data-Filter(242) by Juniper:
https://www.juniper.net/documentation/us/en/software/junos/subscriber-mgmt-services/topics/concept/ascend-data-filter-fields.html
As you can see from that table, a format for both ipv4 and ipv6 filter is defined, and the data length for ipv6 rules can be calculated as 48 octets.

The following published document could be useful as well:
https://www.juniper.net/documentation/us/en/software/junos/subscriber-mgmt-services/topics/concept/subscriber-management-ascend-data-filters.html

[alandekok]

I've pushed changes to the v3.2.x branch. Please try them out.