On 30 May 2014, at 08:39, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 30 May 2014, at 06:02, Nick Lowe <nick.lowe@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@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2