Single RADIUS Class attribute supported by HP's Comware - Bug or Enhancement?

[Arran Cudbard-Bell]

On 30 May 2014, at 08:39, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:

> 
> On 30 May 2014, at 06:02, Nick Lowe <nick.lowe at gmail.com> wrote:
> 
>> Thanks!
>> 
>> They do return a single Class attribute so they are already
>> impementing that SHOULD aspect of the RFC, just not properly as
>> multiples must be supported if this feature is implemented.
>> 
>> "5.44.  Table of Attributes
>> 
>>  The following table provides a guide to which attributes may be found
>>  in which kinds of packets, and in what quantity.
>> 
>>  Request   Accept   Reject   Challenge   #    Attribute
>>  0         0+       0        0           25   Class"
> 
> I'd say HP are doing a pretty good job of being RFC compliant by only 
> returning a single value. It's what the vast majority of vendors do.
> 
> Why do you need more than 253 bytes of class string anyway?

Eesh, starting to sound a vendor, that's bad.

The slight irony there is I too did battle (between 2008-2010) with HP 
(when they were still ProCurve) over many AAA Features, and got them
to increase the class length from something stupidly small to it's current
size (I think it's still actually only 200 bytes or something).

I didn't realise the issue at the time, but thinking about it now it's
almost certainly because they're using a fixed length char buffer in the
struct they're using to represent VPs, and they wanted to reduce memory
usage by setting the max string size to something less than 253 bytes, as
normally the switch would never generate such a long value internally.

But anyway, you can pack multiple attributes into the Class attribute
either as text or binary, so i'm just not sure there's a real requirement
for multiple Class attributes, other than making your implementation 
simpler.

Use %{string:&Class} to convert the contents back to a printable string.

If you really want to fight them, then yes the argument is that returning 
only a single attribute is not within the spirit of the RFC as it clearly 
states that multiple Class attributes may be present in the Access-Accept.

They should either implement the feature fully as the RFC intended or not 
at all. Anything else is confusing for customers, and non compliant.

Alan D or Stefan W should be able to comment on half implementations of 
'SHOULDS' and whether they're compliant or not.

Annoyingly the RFC doesn't provide an upper bound, and that might be why 
they only chose to store a single attribute given the extremely memory
constrained environment code is running in.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140530/30537035/attachment.pgp>