Single RADIUS Class attribute supported by HP's Comware - Bug or Enhancement?
Dear list, Via a support case, I have been trying to get HP to resolve what I believe to be a bug in Comware, used in HP/H3C/3Com networking products. These devices only support a single Class attribute, accounting only with the first Class attribute received in an Access-Accept packet. I have had a support case open since January 2014 to get a code fix for this and they have finally come up with the following: "The current code customer is running is built with limited RFC and any addition of the RFC would be an Enhancement and which we would not be able to change it with these code" This seems obviously incorrect as, to my mind, there is simply no such thing as 'limited RFC' support. Either a product complies with a standard or it does not. There will be parts of the RFCs that are not applicable to certain NASes but that is not the case here. Their products are documented as complying to RFC 2865 and RFC 2866, so I cannot see how this is in any way whatsoever an enhancement request. It is surely just a bug. Please can I get some weight of consensus here that this is just as absurd as I think it is from others experienced in the RADIUS space? I am not pleased to be experiencing such dysfunctional support from HP. Thanks, Nick
Nick Lowe wrote:
This seems obviously incorrect as, to my mind, there is simply no such thing as 'limited RFC' support. Either a product complies with a standard or it does not.
For client behavior, RFC 2865 says specifically: "This Attribute is available to be sent by the server to the client in an Access-Accept and SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported." RFC2865 cites RFC2119 for common definitions and RFC 2119 defines SHOULD as: "SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." This puts you in the gray area where vendors can mince words. They can claim that they have "valid reasons" even if they refuse to specify them or the offered reasons are tenuous. Unless there is language buried in RFC2865 that says one MUST not treat all instances of the same attribute equally, their behavior can be interpreted as just ignoring that SHOULD. For behavior as a proxy or forwarder the term MUST is used so there is less wiggle room there.
Their products are documented as complying to RFC 2865 and RFC 2866, so I cannot see how this is in any way whatsoever an enhancement request.
RFC 2865 qualifies its citation of RFC 2119 thusly: 'An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the must and must not requirements but not all the should or should not requirements for its protocols is said to be "conditionally compliant".' Vendors rarely claim compliance/conformance using those exact words. Often they just list RFCs in a "Features" list or say the product "supports" the RFC, which are meaningless statements, really. There are a lot of non-compliant RADIUS implementations out there, sold by major vendors, with glaring bugs that never get fixed. Large contracts tend to be the major driver for code improvements, so the small customer is mostly left to subsist on the table scraps left over after the large RFPs have had their needs serviced.
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" Nick On Fri, May 30, 2014 at 12:50 PM, Brian Julin <BJulin@clarku.edu> wrote:
Nick Lowe wrote:
This seems obviously incorrect as, to my mind, there is simply no such thing as 'limited RFC' support. Either a product complies with a standard or it does not.
For client behavior, RFC 2865 says specifically:
"This Attribute is available to be sent by the server to the client in an Access-Accept and SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported."
RFC2865 cites RFC2119 for common definitions and RFC 2119 defines SHOULD as:
"SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."
This puts you in the gray area where vendors can mince words. They can claim that they have "valid reasons" even if they refuse to specify them or the offered reasons are tenuous. Unless there is language buried in RFC2865 that says one MUST not treat all instances of the same attribute equally, their behavior can be interpreted as just ignoring that SHOULD.
For behavior as a proxy or forwarder the term MUST is used so there is less wiggle room there.
Their products are documented as complying to RFC 2865 and RFC 2866, so I cannot see how this is in any way whatsoever an enhancement request.
RFC 2865 qualifies its citation of RFC 2119 thusly:
'An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the must and must not requirements but not all the should or should not requirements for its protocols is said to be "conditionally compliant".'
Vendors rarely claim compliance/conformance using those exact words. Often they just list RFCs in a "Features" list or say the product "supports" the RFC, which are meaningless statements, really.
There are a lot of non-compliant RADIUS implementations out there, sold by major vendors, with glaring bugs that never get fixed. Large contracts tend to be the major driver for code improvements, so the small customer is mostly left to subsist on the table scraps left over after the large RFPs have had their needs serviced.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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? Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
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
It is unfortunately to work around another bug in Microsoft's NPS where the Class attribute it generates is not made available via its extensions API. Neither side is yielding yet... The problem comes from an intersection of the two issue. Nick
On 30 May 2014, at 09:11, Nick Lowe <nick.lowe@gmail.com> wrote:
It is unfortunately to work around another bug in Microsoft's NPS where the Class attribute it generates is not made available via its extensions API.
Limited sympathy then :) Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi,
Alan D or Stefan W should be able to comment on half implementations of 'SHOULDS' and whether they're compliant or not.
The thread unveiled two issues: * values with a length "near" 253 characters might cause undesired behaviour * several instances of Class are ignored; only the first instance is returned For the former case, this would be clearly a bug. The RFC very clearly states that the data type is String, which can be up to 253 bytes. Not delivering this in the product IMHO means it is violating the spec outright. For the latter issue, a "SHOULD" and its equivalent "RECOMMENDED" has a well-defined meaning in theory (" SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. ") [RFC 2119, section 3.3] but in practice this just means "Ignore it if you want" (because there are always some "particular circumstances" if you need an excuse). So when the client receives N Class attributes, yes, it SHOULD send them all back, but if it doesn't, too bad. Greetings, Stefan
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
- 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
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. The issue becomes a bug when Class support has been implemented and it does not work as the standard says it should. The RFC is very clear on the expected quantities for a particular attribute type. Clearly it cannot be unbounded due to resource constraints, but not offering even a minimum of two Class attibutes cannot be right. Nick
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
Nick Lowe wrote:
This seems obviously incorrect as, to my mind, there is simply no such thing as 'limited RFC' support. Either a product complies with a standard or it does not.
Unfortunately, that's not how RADIUS works. The documents have a number of SHOULD and SHOULD NOT statements. These make the specs very flexible. The documents are also *silent* on a number of subjects. This makes certain insane behavior "allowed", because it's not forbidden. :( As for the Class attribute, pretty much every NAS vendor supports one, and only one Class attribute. If you're lucky, they support more than 8 bytes for Class. Asking anyone to support multiple Class attributes is probably a waste of time.
Please can I get some weight of consensus here that this is just as absurd as I think it is from others experienced in the RADIUS space?
Most of the RADIUS space is absurd. To be honest, there's probably another way to solve the problem you're seeing. Describe it in detail, and we may be able to help you. Alan DeKok.
participants (5)
-
Alan DeKok -
Arran Cudbard-Bell -
Brian Julin -
Nick Lowe -
Stefan Winter