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

[Stefan Winter]

Hi,

> The way I read the RFC, you either implement Class attribute support
> completely or not at all in a NAS.
> 
> The SHOULD part therefore applies to supporting the Class attribute in
> the first place, not to implementing it in a broken, non-standard way
> that breaks the RFC.

No, the text is:

"[Class] SHOULD be sent unmodified by the client to
      the accounting server as part of the Accounting-Request packet if
      accounting is supported.
"

Say it gets six Class attributes, and returns one only. -> It did modify
the reply, which it SHOULD NOT, but at least it does send a reply.

You could even go further and say that even if it does not send any of
those Class attributes back, it would still be compliant. Not sending
any is "modifying by truncating to the length of 0" :-)

So really, the only solid argument to be made would be if sending Class
once or more times would make the product crash. So long as it can
successfully "absorb" the information, the SHOULD-only in the spec text
makes for an argument for the equipment manufacturer why this could be
seen as an enhancement, not a bug.

I'm not saying that I like or support that kind of attitude. Of course
"the right thing" for the box to do would be to return all those
attributes. But it's difficult to enforce, and if you are talking to
unwilling people on the other end, then that's tough.

You can of course re-think if you want to continue buying stuff from
that vendor. Just saying. Vote-by-wallet is pretty much the only solid
argument that counts in the commercial world.

> The issue becomes a bug when Class support has been implemented and it
> does not work as the standard says it should.

That's the point; there are some things the standard says MUST be done -
if you do those not or incorrectly, then it's violating the standard. If
the standard merely advises implementations that they SHOULD do
something, they are by no means obliged to. They can do other things,
arguing that "circumstance" requires them to do so.

> The RFC is very clear on the expected quantities for a particular
> attribute type.

Yes, but it's also very clear in that modifications of the reply for any
given input in the attribute are possible, even if frowned upon.

> Clearly it cannot be unbounded due to resource constraints, but not
> offering even a minimum of two Class attibutes cannot be right.

"Unbounded" sounds much more threatening than it is in reality anyway.
The maximum length of a RADIUS packet is 4096 bytes; meaning 16
attributes of 253 each are the maximum you need to cater for. Given that
the same equipment needs to have large-enough buffers for other
length-hungry attributes such as multiple occurences of EAP-Message, I
don't think there is much of an argument to be made about unbearable
implementation cost.

Greetings,

Stefan Winter

> 
> Nick
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> 


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x8A39DC66.asc
Type: application/pgp-keys
Size: 3243 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140530/ffd3caea/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140530/ffd3caea/attachment.pgp>