Acct-Authentic in Accounting-On and Accounting-Off forms of Accounting-Request. Valid?
Hi all, I have been assisting Aerohive with an interop issue with Cisco's ACS whereby that RADIUS server would drop/reject the Accounting-On and Accounting-Off forms of Accounting-Request packets that Aerohive's APs are sending, spamming the log with the following error: "RADIUS packet contains invalid attribute(s)" A quick look at this showed that they were including the Acct-Terminate-Cause attribute in the Accounting-On and Accounting-Off forms of Accounting-Request packet which, by spec, is strictly invalid: 5.10. Acct-Terminate-Cause Description This attribute indicates how the session was terminated, and can only be present in Accounting-Request records where the Acct- Status-Type is set to Stop. Aerohive have now fixed this in a forthcoming software update that should resolve the interop issue.
From reviewing that, I had a related question about the Acct-Authentic attribute in Accounting-On and Accounting-Off.
Aerohive are presently including this too. Is this valid? The spec says: 5.6. Acct-Authentic Description This attribute MAY be included in an Accounting-Request to indicate how the user was authenticated, whether by RADIUS, the NAS itself, or another remote authentication protocol. Users who are delivered service without being authenticated SHOULD NOT generate Accounting records.
From my reading, it appears to only be semantically valid in the context of a session and therefore it should not be present.
Other vendors, such as Ruckus, do however document that they include this attribute in Accounting-On and Accounting-Off: http://a030f85c1e25003d7609-b98377aee968aad08453374eb1df3398.r40.cf2.rackcdn... (Ruckus also document that they are not including a Called-Station-Id in their Accounting-On and Accounting-Off with the BSSID/SSID, scoping instead to a SSID with a 'Ruckus-SSID' VSA, yuck!) It appears to be a grey area therefore. Is there a legitimate purpose to including this attribute here? Should it be removed from such packets? Cheers, Nick
On May 21, 2015, at 7:07 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
I have been assisting Aerohive with an interop issue with Cisco's ACS whereby that RADIUS server would drop/reject the Accounting-On and Accounting-Off forms of Accounting-Request packets that Aerohive's APs are sending, spamming the log with the following error: "RADIUS packet contains invalid attribute(s)"
I'll have to bug my contacts at Aerohive... they should know better.
A quick look at this showed that they were including the Acct-Terminate-Cause attribute in the Accounting-On and Accounting-Off forms of Accounting-Request packet which, by spec, is strictly invalid:
It's dumb, but a (cough) sane RADIUS server won't blow up when it receives that kind of "invalid" packet.
Aerohive have now fixed this in a forthcoming software update that should resolve the interop issue.
There's a list of other dumb things they do. I'll push them.
From reviewing that, I had a related question about the Acct-Authentic attribute in Accounting-On and Accounting-Off.
Aerohive are presently including this too. Is this valid?
It makes no sense. It's an attribute which describes a session. It has no meaning for "on" or "off" packets.
From my reading, it appears to only be semantically valid in the context of a session and therefore it should not be present.
Yes.
Other vendors, such as Ruckus, do however document that they include this attribute in Accounting-On and Accounting-Off:
http://a030f85c1e25003d7609-b98377aee968aad08453374eb1df3398.r40.cf2.rackcdn...
That's dumb. It's not forbidden by the spec, because the spec authors don't think anyone would be dumb enough to do it.
(Ruckus also document that they are not including a Called-Station-Id in their Accounting-On and Accounting-Off with the BSSID/SSID, scoping instead to a SSID with a 'Ruckus-SSID' VSA, yuck!)
Huh? There's no reason to include Called-Station-Id with Accounting-On or Accounting-Off. It's stupid.
It appears to be a grey area therefore. Is there a legitimate purpose to including this attribute here? Should it be removed from such packets?
They shouldn't be in the packets. Point your Aerohive contact to me. I'll set them straight. Alan DeKok.
Thanks for the confirmation, Alan! :) The Called-Station-Id is actually really useful as it defines the scope of the Accounting-On/Accounting-Off which are sent here on a per-BSS basis for the 802.11 NAS. Eg: Called-Station-Id: 40-18-B1-AB-CD-EF:MySSID (BSSID:SSID) Otherwise, I cannot see how you would properly handle the Accounting-On and Accounting-Off correctly as BSSes are brought up and down with a configuration change. To reconcile/link them to the subsequent accounting on a per-session basis, it seems necessary. The format is defined for auth under RFC 3580: 3.20. Called-Station-Id For IEEE 802.1X Authenticators, this attribute is used to store the bridge or Access Point MAC address in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". In IEEE 802.11, where the SSID is known, it SHOULD be appended to the Access Point MAC address, separated from the MAC address with a ":". Example "00-10-A4-23-19-C0:AP1". I think it makes a lot of sense for Accounting-On and Accounting-Off therefore to include this in a Called-Station-Id attribute. On the Aerohive front, all the RADIUS accounting will include an Event-Timestamp and Acct-Delay-Time in the forthcoming release, that isn't the case today. They have also added the Message-Authenticator AVP to non-EAP based Access-Request packets for the forthcoming release too. (Enabled as an option, disabled by default.) There are a couple of other issues that I have noticed that will still need resolving in a subsequent release, things like the Accounting-On and Accounting-Off not being retried if no ACK is received. In the beta that I am testing, they are now sending an Accounting-Off and Accounting-On at boot with the same Event-Timestamp in very quick succession. (They need to just send Accounting-On at this point really.) If you make a configuration change that requires a BSS to go up and down, they send an Accounting-Off and Accounting-On, expected behaviour, but currently with the same Event-Timestamp with the two packets being sent in very quick succession. (Previously it was just two packets in quick succession with no Event-Timestamp or Acct-Delay-Time.) This could easily result in out of order receipt, it's UDP after all, or out of order handling at a RADIUS server due to threading. It's race prone. I've suggested that they consider implementing the retransmission behaviour recommended in your excellent RFC 5080. I'm pretty confident they are on the case to improve things. I've been trying to identify and weed out issues so any others you notice it would be good to know about. Thanks again! :) Cheers, Nick
On May 21, 2015, at 9:37 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
Thanks for the confirmation, Alan! :)
The Called-Station-Id is actually really useful as it defines the scope of the Accounting-On/Accounting-Off which are sent here on a per-BSS basis for the 802.11 NAS.
That's a very non-standard use. Accounting-On / Off is supposed to be for the entire NAS. i.e. the WLAN controller / BSS. Not for a particular SSID.
Otherwise, I cannot see how you would properly handle the Accounting-On and Accounting-Off correctly as BSSes are brought up and down with a configuration change.
The BSS should be the RADIUS client.
I think it makes a lot of sense for Accounting-On and Accounting-Off therefore to include this in a Called-Station-Id attribute.
Which, in the normal RADIUS model, is just the MAC address of the RADIUS client. Which never changes. So it's not really useful to send it.
On the Aerohive front, all the RADIUS accounting will include an Event-Timestamp and Acct-Delay-Time in the forthcoming release, that isn't the case today.
Wow... that's bad, but good they've fixed it.
They have also added the Message-Authenticator AVP to non-EAP based Access-Request packets for the forthcoming release too. (Enabled as an option, disabled by default.)
That's a good idea.
There are a couple of other issues that I have noticed that will still need resolving in a subsequent release, things like the Accounting-On and Accounting-Off not being retried if no ACK is received.
That's bad.
In the beta that I am testing, they are now sending an Accounting-Off and Accounting-On at boot with the same Event-Timestamp in very quick succession. (They need to just send Accounting-On at this point really.)
Accounting-Off is for when the NAS is about to reboot. Accounting-On is for when the NAS has just booted.
This could easily result in out of order receipt, it's UDP after all, or out of order handling at a RADIUS server due to threading. It's race prone.
Yes. They're better off just sending an Accounting-On message.
I've suggested that they consider implementing the retransmission behaviour recommended in your excellent RFC 5080.
Yeah... which is years old.
I'm pretty confident they are on the case to improve things. I've been trying to identify and weed out issues so any others you notice it would be good to know about.
They've been sending accounting "stop" packets after an Access-Reject. Uh... no. If the user was rejected, there's no session, and no need for a "stop" packet. I think I should write a "best practices" document for NAS vendors. Alan DeKok.
Hi Alan, A BSS is always unique on a per-VAP basis, so that's per-SSID-per-radio-per-physical-AP. Does the RADIUS spec prohibit accounting on a per-BSS basis, which is the basis of how all APs offer service to clients/stations (STAs)? RFC 3580 does specify that Access-Requests will be scoped to a per-BSSID/per-SSID basis via the Called-Station-Id, so why not implement the same behaviour for accounting? In the Aerohive model, there are no central controllers - each AP is a RADIUS client. Without the Called-Station-Id, there is no specificity to an Accounting-On or Accounting-Off and they become a blunt instrument, and actually rather useless/meaningless. It doesn't match how APs actually operate so things should change. Yes, it has not been traditionally done. The RADIUS accounting spec was written long before wireless NASes existed, but I actually think that it would make sense for all wireless vendors to align to this model - scoping to the BSS with the Called-Station-Id and sending Accounting-On and Accounting-Off on a per-BSS basis (which means sent on a physical AP basis, even where it's actually transmitted by a central controller). This already happens for Access-Request packets, and Accounting-Request packets with Start, Interim-Update and Stop with most vendors in this space via the Called-Station-Id. Appreciate your thoughts! Cheers, Nick
Sorry, less haste more speed... RFC 3580 specifies it's scoped on a per-AP/SSID basis: "In IEEE 802.11, where the SSID is known, it SHOULD be appended to the Access Point MAC address, separated from the MAC address with a ":". Example "00-10-A4-23-19-C0:AP1". Ambiguity: Does this mean the wired or wireless MAC address? Enterprise APs operate these days on a per VAP basis, operating with multiple radios. This wasn't the case when RFC 3580 was written. So, AP vendors should set this value in Access-Request packets with BSSID:SSID, not AP_WIRED_MAC:SSID or CONTROLLER_WIRED_MAC:SSID. Most vendors do, I think, already do this. Perhaps this needs some cogent, joined up thinking to come up with something suited for the future? Cheers, Nick On Thu, May 21, 2015 at 4:53 PM, Nick Lowe <nick.lowe@gmail.com> wrote:
Hi Alan,
A BSS is always unique on a per-VAP basis, so that's per-SSID-per-radio-per-physical-AP.
Does the RADIUS spec prohibit accounting on a per-BSS basis, which is the basis of how all APs offer service to clients/stations (STAs)?
RFC 3580 does specify that Access-Requests will be scoped to a per-BSSID/per-SSID basis via the Called-Station-Id, so why not implement the same behaviour for accounting?
In the Aerohive model, there are no central controllers - each AP is a RADIUS client.
Without the Called-Station-Id, there is no specificity to an Accounting-On or Accounting-Off and they become a blunt instrument, and actually rather useless/meaningless. It doesn't match how APs actually operate so things should change.
Yes, it has not been traditionally done.
The RADIUS accounting spec was written long before wireless NASes existed, but I actually think that it would make sense for all wireless vendors to align to this model - scoping to the BSS with the Called-Station-Id and sending Accounting-On and Accounting-Off on a per-BSS basis (which means sent on a physical AP basis, even where it's actually transmitted by a central controller).
This already happens for Access-Request packets, and Accounting-Request packets with Start, Interim-Update and Stop with most vendors in this space via the Called-Station-Id.
Appreciate your thoughts!
Cheers,
Nick
On May 21, 2015, at 12:14 PM, Nick Lowe <nick.lowe@gmail.com> wrote:
Sorry, less haste more speed... RFC 3580 specifies it's scoped on a per-AP/SSID basis:
"In IEEE 802.11, where the SSID is known, it SHOULD be appended to the Access Point MAC address, separated from the MAC address with a ":". Example "00-10-A4-23-19-C0:AP1".
That's *content*. It's not *scope*. It means that the packets contain ASCII text. It does NOT mean that ASCII text has any *meaning*.
Ambiguity: Does this mean the wired or wireless MAC address?
The standards don't say. It's *a* MAC address.
Enterprise APs operate these days on a per VAP basis, operating with multiple radios. This wasn't the case when RFC 3580 was written. So, AP vendors should set this value in Access-Request packets with BSSID:SSID, not AP_WIRED_MAC:SSID or CONTROLLER_WIRED_MAC:SSID. Most vendors do, I think, already do this.
Perhaps this needs some cogent, joined up thinking to come up with something suited for the future?
It needs a spec, TBH. Alan DeKok.
That's *content*. It's not *scope*.
It means that the packets contain ASCII text. It does NOT mean that ASCII text has any *meaning*.
The standards don't say. It's *a* MAC address.
Ok, conceded and agreed, it is just content and it isn't, by spec, scope. It would be useful to have a spec that states that for 802.11 wireless NASes, this is required to be BSSID:SSID Out of interest, do we know of any enterprise class AP vendors that don't already do this? As far as I know, this is the de facto behaviour that you'll observe in most cases.
On May 21, 2015, at 11:53 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
Hi Alan,
A BSS is always unique on a per-VAP basis, so that's per-SSID-per-radio-per-physical-AP.
Does the RADIUS spec prohibit accounting on a per-BSS basis, which is the basis of how all APs offer service to clients/stations (STAs)?
No, but it also doesn't provide for it.
RFC 3580 does specify that Access-Requests will be scoped to a per-BSSID/per-SSID basis via the Called-Station-Id, so why not implement the same behaviour for accounting?
Because RFC 3580 doesn't say Accounting-Requets will be? RFC 3580's comments are likely about the scope of authentication. i.e. The RADIUS server should perform autz based on the user and the BSSID. RFC 2866 says: 5.1. Acct-Status-Type Description This attribute indicates whether this Accounting-Request marks the beginning of the user service (Start) or the end (Stop). It MAY be used by the client to mark the start of accounting (for example, upon booting) by specifying Accounting-On and to mark the end of accounting (for example, just before a scheduled reboot) by specifying Accounting-Off. A summary of the Acct-Status-Type attribute format is shown below. The fields are transmitted from left to right. A client is a RADIUS client, not a service.
In the Aerohive model, there are no central controllers - each AP is a RADIUS client.
Yes, it's lovely.
Without the Called-Station-Id, there is no specificity to an Accounting-On or Accounting-Off and they become a blunt instrument, and actually rather useless/meaningless.
No, they're still extremely useful just not for your particular use case. If BSSIDs go up/down the AP should send stop messages for the active sessions. If it's not, that's an issue, and that should be fixed. Accounting-On/Off packets have traditionally been a last resort thing, where the system is about to restart, or went down in a non-clean fashion.
It doesn't match how APs actually operate so things should change.
Start attending IETF meetings then.
Yes, it has not been traditionally done.
The RADIUS accounting spec was written long before wireless NASes existed, but I actually think that it would make sense for all wireless vendors to align to this model - scoping to the BSS with the Called-Station-Id and sending Accounting-On and Accounting-Off on a per-BSS basis (which means sent on a physical AP basis, even where it's actually transmitted by a central controller).
This already happens for Access-Request packets, and Accounting-Request packets with Start, Interim-Update and Stop with most vendors in this space via the Called-Station-Id.
It would be useful. But it's pushing the burden of complexity onto the RADIUS server. I think explicit stops are better for normal operation than bulk session closes using Accounting-Off. -Arran
On May 21, 2015, at 11:53 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
Does the RADIUS spec prohibit accounting on a per-BSS basis, which is the basis of how all APs offer service to clients/stations (STAs)?
It's silent on the topic.
RFC 3580 does specify that Access-Requests will be scoped to a per-BSSID/per-SSID basis via the Called-Station-Id,
No. It says that Access-Requests *contain* a Called-Station-Id, which in turn contains a BSSID. There's no concept of "scope". The Called-Station-Id attribute helps to identify a unique user session. But that's all.
so why not implement the same behaviour for accounting?
It's not the same behaviour.
In the Aerohive model, there are no central controllers - each AP is a RADIUS client.
Then when the AP reboots, it sends an Accounting-On message. If a radio box reboots... RADIUS is silent on what happens. If the AP controls 5 radios, and one radio reboots, there is *no* standard RADIUS way of dealing with that. If the AP sends an Accounting-On packet, it's arguably wrong. Because the AP hasn't rebooted.
Without the Called-Station-Id, there is no specificity to an Accounting-On or Accounting-Off and they become a blunt instrument,
That's how RADIUS works. Any non-standard extension is non-standard.
and actually rather useless/meaningless. It doesn't match how APs actually operate so things should change.
Write an RFC. :)
The RADIUS accounting spec was written long before wireless NASes existed, but I actually think that it would make sense for all wireless vendors to align to this model - scoping to the BSS with the Called-Station-Id and sending Accounting-On and Accounting-Off on a per-BSS basis (which means sent on a physical AP basis, even where it's actually transmitted by a central controller).
Sure. Write a document. It's probably wrong to use an Accounting-On message. That already has existing meaning. Instead, there should be a new Acct-Status-Type defined. Call it something else, like "portions of a NAS have rebooted".
This already happens for Access-Request packets, and Accounting-Request packets with Start, Interim-Update and Stop with most vendors in this space via the Called-Station-Id.
No, it doesn't happen in Access-Request or Accounting-Request packets. Those contain session identification attributes. What those attributes are is unspecified, but typically things like Calling-Station-Id and Called-Station-Id. What those attributes contain is also largely unspecified. Their format is defined, but often not their contents. i.e. you're giving *meaning* to those attributes. That's nice, but there's no reason to believe your conclusions are correct. It's RADIUS. Very little makes sense. Other people can (and have) come to completely different conclusions. What you're really looking for is a RADIUS message saying "all sessions matching X have stopped.". There is no standard RADIUS way to do that. You must write a new specification. To be honest, I'm inclined to just start writing specs and putting them up on freeradius.org. There are dozens of things which the IETF will never standardize, but which will be useful for many vendors. Alan DeKok.
No. It says that Access-Requests *contain* a Called-Station-Id, which in turn contains a BSSID. There's no concept of "scope".
The Called-Station-Id attribute helps to identify a unique user session. But that's all.
A BSSID, by its very nature, scopes the authentication if present in the Called-Station-Id along with the SSID. It's implicit that that happens. It doesn't have to be stated explicitly anywhere therefore, surely? It's the nature of what using the BSSID/SSID does.
It's not the same behaviour.
By implement the same behaviour, I meant include a Called-Station-Id with the same format in both auth and accounting for a session.
Then when the AP reboots, it sends an Accounting-On message. If a radio box reboots... RADIUS is silent on what happens.
The RADIUS spec doesn't seem to require that a reboot has happened, or is about to happen?
If the AP controls 5 radios, and one radio reboots, there is *no* standard RADIUS way of dealing with that. If the AP sends an Accounting-On packet, it's arguably wrong. Because the AP hasn't rebooted.
Same point as above.
Write an RFC. :)
Sure. Write a document.
Fair point, I certainly think it needs clarifying in the interests of interoperability and uniformity, however that concludes.
It's probably wrong to use an Accounting-On message. That already has existing meaning. Instead, there should be a new Acct-Status-Type defined. Call it something else, like "portions of a NAS have rebooted".
I guess you're right, it has traditionally been tied to a reboot of the NAS even if not explicitly stated
No, it doesn't happen in Access-Request or Accounting-Request packets. Those contain session identification attributes. What those attributes are is unspecified, but typically things like Calling-Station-Id and Called-Station-Id. What those attributes contain is also largely unspecified. Their format is defined, but often not their contents.
i.e. you're giving *meaning* to those attributes. That's nice, but there's no reason to believe your conclusions are correct. It's RADIUS. Very little makes sense. Other people can (and have) come to completely different conclusions.
I only meant that this does already happen for -most- wireless NAS vendors in the way that they use-and-include the Called-Station-Id in Access-Request packets and Start, Interim-Update and Stop forms of Accounting-Request packet.
To be honest, I'm inclined to just start writing specs and putting them up on freeradius.org. There are dozens of things which the IETF will never standardize, but which will be useful for many vendors.
That would be seriously awesome. Cheers, Nick
On May 21, 2015, at 12:39 PM, Nick Lowe <nick.lowe@gmail.com> wrote:
Then when the AP reboots, it sends an Accounting-On message. If a radio box reboots... RADIUS is silent on what happens.
The RADIUS spec doesn't seem to require that a reboot has happened, or is about to happen?
The specs talk about a RADIUS client. They make NO mention of "radio" versus "wlan controller".
If the AP controls 5 radios, and one radio reboots, there is *no* standard RADIUS way of dealing with that. If the AP sends an Accounting-On packet, it's arguably wrong. Because the AP hasn't rebooted.
Same point as above.
I think you're not understanding what I'm saying. Has the system sending Access-Request packets rebooted? a) no - then it MUST NOT send Accounting-On b) yes - then it SHOULD send Accounting-On
I guess you're right, it has traditionally been tied to a reboot of the NAS even if not explicitly stated
It has EXPLICITLY stated in the specs: It MAY be used by the client to mark the start of accounting (for example, upon booting) by specifying Accounting-On and to mark the end of accounting (for example, just before a scheduled reboot) by specifying Accounting-Off. The RADIUS CLIENT is rebooting. Not a sub-system. Not a card. Not a process re-starting. The RADIUS CLIENT.
I only meant that this does already happen for -most- wireless NAS vendors in the way that they use-and-include the Called-Station-Id in Access-Request packets and Start, Interim-Update and Stop forms of Accounting-Request packet.
It may be common practice, but without a new spec, it's not a standard part of RADIUS. Alan DeKok.
It has EXPLICITLY stated in the specs:
It MAY be used by the client to mark the start of accounting (for example, upon booting) by specifying Accounting-On and to mark the end of accounting (for example, just before a scheduled reboot) by specifying Accounting-Off.
The RADIUS CLIENT is rebooting. Not a sub-system. Not a card. Not a process re-starting. The RADIUS CLIENT.
That -isn't- explicitly stated, it is saying that they should be sent to mark the start or end of accounting - that's not tied to only a startup, a reboot or a shutdown. The spec uses those as examples of when it is appropriate. It doesn't say they are the only times that they can be sent. The spec does not prohibit WLAN vendors scoping the start or end of accounting with a Calling-Station-Id so some seem to have taken that liberty, and send these on a per-BSS basis and not on a per-NAS basis. I agree with you that adding a new Acct-Status-Type would be more appropriate and mandating that Accounting-On and Accounting-Off be sent only on a per-NAS basis would be the best way forward. Yes, we could do with a new spec that cleans this up! :) Nick
On May 21, 2015, at 4:17 PM, Nick Lowe <nick.lowe@gmail.com> wrote:
That -isn't- explicitly stated, it is saying that they should be sent to mark the start or end of accounting - that's not tied to only a startup, a reboot or a shutdown. The spec uses those as examples of when it is appropriate. It doesn't say they are the only times that they can be sent.
If you're going to interpret text as saying the *opposite* of what it says, you can justify anything.
The spec does not prohibit WLAN vendors scoping the start or end of accounting with a Calling-Station-Id so some seem to have taken that liberty, and send these on a per-BSS basis and not on a per-NAS basis.
The specs don't prohibit all kinds of idiotic behaviour. Because, as I said, the authors didn't think that simple text could be misunderstood. Alan DeKok.
On May 22, 2015, at 2:47 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
If you're going to interpret text as saying the *opposite* of what it says, you can justify anything.
I'm playing devil's advocate somewhat here,
I already know that people can come up with the most ridiculous interpretations of the specs. I've said so repeatedly in this thread. There's no need to advocate for a ridiculous interpretation when I've already admitted it exists. In this content, arguing for ridiculous interpretations isn't playing devils advocate. It's poking me with a sharp stick, and then acting surprised when I get cranky. Alan DeKok.
Hugs? :) I've pinged the appropriate people in Aerohive to ask if they will considering implementing the ability to have per-NAS behaviour with Accounting-On and Accounting-Off for those who demand or want it. It should clearly be the default, without a Called-Station-Id being present. There should probably also be a configuration option to enable the incumbent behaviour that they have implemented for those who have a dependency or need for the way it's working. Cheers, Nick
On 22 May 2015, at 08:40, Nick Lowe <nick.lowe@gmail.com> wrote:
Hugs? :)
I've pinged the appropriate people in Aerohive to ask if they will considering implementing the ability to have per-NAS behaviour with Accounting-On and Accounting-Off for those who demand or want it. It should clearly be the default, without a Called-Station-Id being present.
Don't overload existing behaviour with toggles, it makes things really confusing.
There should probably also be a configuration option to enable the incumbent behaviour that they have implemented for those who have a dependency or need for the way it's working.
Or use a different Acct-Status-Type values for BSSID up/down (as Alan suggested offline). -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
They've been sending accounting "stop" packets after an Access-Reject. Uh... no. If the user was rejected, there's no session, and no need for a "stop" packet.
Just a FYI, I can't reproduce this in the beta code that I am testing - I presume it has been fixed at some point.
On May 21, 2015, at 7:07 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
I have been assisting Aerohive with an interop issue with Cisco's ACS whereby that RADIUS server would drop/reject the Accounting-On and Accounting-Off forms of Accounting-Request packets that Aerohive's APs are sending, spamming the log with the following error: "RADIUS packet contains invalid attribute(s)"
I'll have to bug my contacts at Aerohive... they should know better.
A quick look at this showed that they were including the Acct-Terminate-Cause attribute in the Accounting-On and Accounting-Off forms of Accounting-Request packet which, by spec, is strictly invalid:
It's dumb, but a (cough) sane RADIUS server won't blow up when it receives that kind of "invalid" packet.
Aerohive have now fixed this in a forthcoming software update that should resolve the interop issue.
There's a list of other dumb things they do. I'll push them.
From reviewing that, I had a related question about the Acct-Authentic attribute in Accounting-On and Accounting-Off.
Aerohive are presently including this too. Is this valid?
It makes no sense. It's an attribute which describes a session. It has no meaning for "on" or "off" packets.
From my reading, it appears to only be semantically valid in the context of a session and therefore it should not be present.
Yes.
Other vendors, such as Ruckus, do however document that they include this attribute in Accounting-On and Accounting-Off:
http://a030f85c1e25003d7609-b98377aee968aad08453374eb1df3398.r40.cf2.rackcdn...
That's dumb. It's not forbidden by the spec, because the spec authors don't think anyone would be dumb enough to do it.
(Ruckus also document that they are not including a Called-Station-Id in their Accounting-On and Accounting-Off with the BSSID/SSID, scoping instead to a SSID with a 'Ruckus-SSID' VSA, yuck!)
Huh? There's no reason to include Called-Station-Id with Accounting-On or Accounting
It appears to be a grey area therefore. Is there a legitimate purpose to including this attribute here? Should it be removed from such packets?
Cheers,
Nick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Nick Lowe