NSAPI changes Acct-Session-Id from upstream provider
Hi Guys This might be off topic but I was wondering if someone with more knowledge than me, would be able to confirm the following :- In a mobile network scenario with thousands of IoT devices On our radius servers, we've been noticing a lot of 0-byte sessions on our databases and upon investigation, we've seen the following behaviour :-
Authentication Request Received < Access Accept sent back Accounting Start Packet Received with a Acct-Session-Id < Acknowledgement sent back Interim Accounting Packet Received - This time with a different Acct-Session-Id for the same connection
** At this point, things start going bad as we are not able to update the original DB entry created with the Acct Start Packet, since the Acct-Session-Id differs between the packet received in the Accounting Start Packet and the Interim Accounting Packet. This results in a 0-session entry in the DB for the Accounting Start Packet entry as a new entry is written into the DB based on the new Acct-Session-Id received in the Interim Accounting packet. Any subsequent packets received with a different Acct-Session-Id, results in writing a new DB entry when the Interim Accounting Packet is received. We queried this with the upstream provider, and they advised that the 3GPP-NSAPI number changes when packets are received and they claim that the Acct-Session-Id on their side would change based on the 3GPP-NSAPI value that could (and in most cases) changes. < Acknowledgement Sent back
From what I've been reading, The Acct-Session-Id should remain constant for the entire PDP context/session, even when the NSAPI changes because the Acct-Session-Id is meant to uniquely identify the entire user session. NSAPI changes are considered sub-sessions within the main PDP context and keeping the same Acct-Session-Id helps maintain session continuity for billing and tracking purposes, which is exactly our use case for accounting which is not working as expected.
Any thoughts and insights would be appreciated if someone faced a similar situation. Many thanks, Gabriel
On 24/02/2025 07:05, Gabriel Marais wrote:
Authentication Request Received < Access Accept sent back Accounting Start Packet Received with a Acct-Session-Id < Acknowledgement sent back Interim Accounting Packet Received - This time with a different Acct-Session-Id for the same connection
That's just broken. RFC 2866 s5.5 and 2869 s2.1 make it clear that Acct-Session-Id must match across the whole session. Those documents have only been published for nearly 25 years :( Common sense says the same, too.
** At this point, things start going bad as we are not able to update the original DB entry created with the Acct Start Packet, since the Acct-Session-Id differs between the packet received in the Accounting Start Packet and the Interim Accounting Packet.
Yeah, quite. The behaviour needs fixing or the kit needs throwing in the bin and replacing with something sane. -- Matthew
On Feb 24, 2025, at 4:56 AM, Matthew Newton via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
That's just broken. RFC 2866 s5.5 and 2869 s2.1 make it clear that Acct-Session-Id must match across the whole session. Those documents have only been published for nearly 25 years :(
Not quite. :( RFC 2866 Section 5.5 says the Acct-Session-ID MUST match across start and stop/ RFC 2869 Section 2.1 defines interim-updates, but doesn't mandate that Acct-Session-Id matches the one in start / stop packet. Instead, it says: It is envisioned that an Interim Accounting record (with Acct- Status-Type = Interim-Update (3)) would contain all of the attributes normally found in an Accounting Stop message Which is missing text like "MUST contain". And yes, I've spent years working with equipment vendors who see that, and go "HA HA, we're allowed to do this!". For some reason, they are incapable of understanding that their customers want their product to work in a sane fashion.
Common sense says the same, too.
While I agree, some vendors seem to take a perverse and near psychopathic joy in making the most bizarre and ludicrous interpretation of the RFCs. If anyone thinks this is an exaggeration, you should see my inbox. The IETF RADEXT working group has a Wiki devoted to weird and stupid behavior from vendors: https://github.com/radext-wg/issues-and-fixes-2/wiki I'll update that with the issues raised in this thread. I've also written a section in an upcoming RFC about the pattern of interpreting the RFCs in weird and wonderful ways: https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius-0...
Yeah, quite. The behaviour needs fixing or the kit needs throwing in the bin and replacing with something sane.
Yup. Alan DeKok.
We have seen similar cases, and were able to use the IMEISV field to identify the devices on our APN's. It seems that there are some newer devices that attempt to build connections on top of a connection, even if it has not accepted the Access-Accept Response even though it was Authenticated. The connectivity is too slow, and it is being dropped, more specifically to Ericsson APN systems. We had to ensure that the APN was enforcing "Simultaneous-Use = 1" and that the Session Timeout did not exceed 1 day. Further to this, we had to get the developers for the devices involved, because they were taking short-cuts to ensure connectivity as fast as possible instead of complying with the AAA standards. On some devices, the number of connectivity attempts was 19 before the Radius had even responded with the Access-Accept, each with their own Session-Id to the same device. Most of these devices had modems made in China, but not all. On 2025/02/24 09:05, Gabriel Marais wrote:
Hi Guys
This might be off topic but I was wondering if someone with more knowledge than me, would be able to confirm the following :-
In a mobile network scenario with thousands of IoT devices
On our radius servers, we've been noticing a lot of 0-byte sessions on our databases and upon investigation, we've seen the following behaviour :-
Authentication Request Received < Access Accept sent back Accounting Start Packet Received with a Acct-Session-Id < Acknowledgement sent back Interim Accounting Packet Received - This time with a different Acct-Session-Id for the same connection ** At this point, things start going bad as we are not able to update the original DB entry created with the Acct Start Packet, since the Acct-Session-Id differs between the packet received in the Accounting Start Packet and the Interim Accounting Packet.
This results in a 0-session entry in the DB for the Accounting Start Packet entry as a new entry is written into the DB based on the new Acct-Session-Id received in the Interim Accounting packet.
Any subsequent packets received with a different Acct-Session-Id, results in writing a new DB entry when the Interim Accounting Packet is received.
We queried this with the upstream provider, and they advised that the 3GPP-NSAPI number changes when packets are received and they claim that the Acct-Session-Id on their side would change based on the 3GPP-NSAPI value that could (and in most cases) changes.
< Acknowledgement Sent back
From what I've been reading, The Acct-Session-Id should remain constant for the entire PDP context/session, even when the NSAPI changes because the Acct-Session-Id is meant to uniquely identify the entire user session. NSAPI changes are considered sub-sessions within the main PDP context and keeping the same Acct-Session-Id helps maintain session continuity for billing and tracking purposes, which is exactly our use case for accounting which is not working as expected.
Any thoughts and insights would be appreciated if someone faced a similar situation.
Many thanks, Gabriel - List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html
On Feb 24, 2025, at 5:14 AM, Conrad Classen <conrad.classen@gmail.com> wrote:
We have seen similar cases, and were able to use the IMEISV field to identify the devices on our APN's.
Were other attributes for the session stable? i.e. NAS-IP-Address, NAS-Port, etc. If so, that could help too. Note that RFC 2866 doesn't say that the values of NAS-Identifier, etc. must be stable across all accounting packets for one session. So yes, there are vendors who send different values.
It seems that there are some newer devices that attempt to build connections on top of a connection, even if it has not accepted the Access-Accept Response even though it was Authenticated.
<sigh> I've updated the RADEXT Wiki with this information.
Further to this, we had to get the developers for the devices involved, because they were taking short-cuts to ensure connectivity as fast as possible instead of complying with the AAA standards.
For the future, please reach out to me via email. I am more than happy to join any conversions via email, or even calls, no matter what the time / time zone. These kind of issues cost me time and money. They cost FreeRADIUS users time and money. It's worth my time to join any conversation about broken NAS equipment, and then to pull rank on the vendor. I've generally
On some devices, the number of connectivity attempts was 19 before the Radius had even responded with the Access-Accept, each with their own Session-Id to the same device.
I can't even imagine the situation where this would ever be a good idea. The vendors are going out of their way to do extra work which is stupid, useless, and broken. At this point, it looks like it's becoming necessary to update the RADIUS RFCs. That is generally the only way to fight back against such vendor craziness. Alan DeKok.
On Mon, Feb 24, 2025 at 3:01 PM Alan DeKok <aland@deployingradius.com> wrote:
On Feb 24, 2025, at 5:14 AM, Conrad Classen <conrad.classen@gmail.com> wrote:
We have seen similar cases, and were able to use the IMEISV field to identify the devices on our APN's.
Were other attributes for the session stable? i.e. NAS-IP-Address, NAS-Port, etc. If so, that could help too.
Note that RFC 2866 doesn't say that the values of NAS-Identifier, etc. must be stable across all accounting packets for one session. So yes, there are vendors who send different values.
In my case, NAS-IP-Address, NAS-Identifier and NAS-Port-Type was the same. I only get NAS-Port on Access-Requests but not on any subsequent Accounting packets...
It seems that there are some newer devices that attempt to build connections on top of a connection, even if it has not accepted the Access-Accept Response even though it was Authenticated.
<sigh> I've updated the RADEXT Wiki with this information.
Further to this, we had to get the developers for the devices involved, because they were taking short-cuts to ensure connectivity as fast as possible instead of complying with the AAA standards.
For the future, please reach out to me via email. I am more than happy to join any conversions via email, or even calls, no matter what the time / time zone.
These kind of issues cost me time and money. They cost FreeRADIUS users time and money. It's worth my time to join any conversation about broken NAS equipment, and then to pull rank on the vendor.
I've generally
On some devices, the number of connectivity attempts was 19 before the Radius had even responded with the Access-Accept, each with their own Session-Id to the same device.
I can't even imagine the situation where this would ever be a good idea. The vendors are going out of their way to do extra work which is stupid, useless, and broken.
At this point, it looks like it's becoming necessary to update the RADIUS RFCs. That is generally the only way to fight back against such vendor craziness.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi Alan On 2025/02/24 15:00, Alan DeKok wrote:
On Feb 24, 2025, at 5:14 AM, Conrad Classen<conrad.classen@gmail.com> wrote:
We have seen similar cases, and were able to use the IMEISV field to identify the devices on our APN's. Were other attributes for the session stable? i.e. NAS-IP-Address, NAS-Port, etc. If so, that could help too.
Note that RFC 2866 doesn't say that the values of NAS-Identifier, etc. must be stable across all accounting packets for one session. So yes, there are vendors who send different values. The NAS-IP-ADDRESS did not change unless there were two or more GGSN's working together to accept requests for load balancing purposes. then the multiple sessions were established over all, which each having a different NAS-IP-ADDRESS
We had to eventually request that the additional GGSN's were removed so that we could dig deeper into what the issues were. As usual, the ISP's are not very forth coming in accepting that the problems seen were partly due to their configurations. I had to copy/paste the from the RFC's to them to show that they had things wrong.
It seems that there are some newer devices that attempt to build connections on top of a connection, even if it has not accepted the Access-Accept Response even though it was Authenticated. <sigh> I've updated the RADEXT Wiki with this information.
Further to this, we had to get the developers for the devices involved, because they were taking short-cuts to ensure connectivity as fast as possible instead of complying with the AAA standards. For the future, please reach out to me via email. I am more than happy to join any conversions via email, or even calls, no matter what the time / time zone.
These kind of issues cost me time and money. They cost FreeRADIUS users time and money. It's worth my time to join any conversation about broken NAS equipment, and then to pull rank on the vendor.
I've generally
On some devices, the number of connectivity attempts was 19 before the Radius had even responded with the Access-Accept, each with their own Session-Id to the same device. I can't even imagine the situation where this would ever be a good idea. The vendors are going out of their way to do extra work which is stupid, useless, and broken.
At this point, it looks like it's becoming necessary to update the RADIUS RFCs. That is generally the only way to fight back against such vendor craziness.
Alan DeKok.
- List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html
On Feb 24, 2025, at 10:07 AM, Conrad Classen <conrad.classen@gmail.com> wrote:
The NAS-IP-ADDRESS did not change unless there were two or more GGSN's working together to accept requests for load balancing purposes. then the multiple sessions were established over all, which each having a different NAS-IP-ADDRESS
Oh boy. I'll update the RADEXT wiki. If GGSNs are doing load balancing for a user session, then they should coordinate to use the same Acct-Session-ID or Acct-Multi-Session-ID. Nothing else makes sense.
I had to copy/paste the from the RFC's to them to show that they had things wrong.
Yup. Alan DeKok.
On Mon, Feb 24, 2025 at 12:15 PM Conrad Classen <conrad.classen@gmail.com> wrote:
We have seen similar cases, and were able to use the IMEISV field to identify the devices on our APN's.
It seems that there are some newer devices that attempt to build connections on top of a connection, even if it has not accepted the Access-Accept Response even though it was Authenticated.
I'm currently testing with a Huawei B535-932 router but the experience is the same for probably all of our customers' IoT devices.
From what I've seen, if I force the router to only connect on 3G, I get one Session - Start to Finish and with a single Acct-Session-Id - Everything seems to work perfectly. If I force the router to use 4G only, then I see multiple connections. Almost like it's establishing connections on top of connections.
When the router boots up and latches to the network, I get an authentication request. Once the auth request is accepted, I get the accounting start packet and subsequent interim updates. All of the updates are with 0 Acct-Input-Octets and Acct-Ouput-Octets. At this stage the router has not made any data connection to the network, it has only latched onto the network. As soon as I enable the mobile data connection, that's where things get interesting.
New Authentication Request < Access Accept sent back
Accounting Stop packet for the initial auth request "to latch onto the network" < Sent Accounting response
Receive Accounting Start Packet - B9033604530D06A0 < Sent Accounting Response
Receive Account Stop Packet - B9033604530D06A0 - Acct-Terminate-Cause = NAS-Request ** < Sent Accounting Response
Receive Access Request - NSAPI 5 < Access Accept sent back
Receive Accounting Start Packet - B9033604530D00CE - NSAPI 5 < Sent Accounting Response
Receive Access Request - NSAPI 6 < Access Accept sent back
Receive Accounting Request - Stop Packet - B9033604530D00CE - NSAPI 5 < Sent Accounting Response
Receive Accounting Request - Start Packet - B903360453110451 - NSAPI 6 < Sent Accounting Response
Receive Auth Request - NSAPI 5 < Sent Access Accept
Receive Accounting Request - Start - B903360453050473 - NSAPI 5 < Sent Accounting Response
Receive Accounting Request - Stop - B903360453110451 - NSAPI 6 < Sent Accounting Response
Receive Access Request - NSAPI 6 < Sent Access Accept
Receive Accounting Request - Start - B90336045315039C - NSAPI 6 < Sent Accounting Response
Receive Accounting Request - Interim Update - B903360453050473 - NSAPI 5 | Acct-Input-Octets = 1742 | Acct-Output-Octets = 0 < Sent Accounting Response Received Accounting Request - Interim Update - B90336045315039C - NSAPI 6 | Acct-Input-Octets = 0 | Acct-Output-Octets = 5279 < Sent Accounting Response Received Accounting Request - Interim Update - B903360453050473 - NSAPI 5 | Acct-Input-Octets = 1742 | Acct-Output-Octets = 0 < Sent Accounting Response
Disabling the Data Session :
Received Accounting Request - Stop - B90336045315039C - NSAPI 6 | Acct-Input-Octets = 0 | Acct-Output-Octets = 9936 < Sent Accounting Response
Received Accounting Request - Stop - B903360453050473 - NSAPI 5 | Acct-Input-Octets = 3197 | Acct-Output-Octets = 0 < Sent Accounting Response
To me, it looks like on 4G, there are two sessions being established, one for "up" traffic and one for "down" traffic as I have noticed that those interim accounting packets only ever contain either Acct-Input-Octets = 0 **or** Acct-Output-Octets = 0 and the NSAPI values are 5 and 6. In which case, the Acct-MultiSession-Id would have been great to track usage on sessions within the same "session", although I'm not sure if this would be seen as a MultiSession?
The connectivity is too slow, and it is being dropped, more specifically to Ericsson APN systems. We had to ensure that the APN was enforcing "Simultaneous-Use = 1" and that the Session Timeout did not exceed 1 day.
Further to this, we had to get the developers for the devices involved, because they were taking short-cuts to ensure connectivity as fast as possible instead of complying with the AAA standards.
On some devices, the number of connectivity attempts was 19 before the Radius had even responded with the Access-Accept, each with their own Session-Id to the same device.
Most of these devices had modems made in China, but not all.
Hi Guys
This might be off topic but I was wondering if someone with more knowledge than me, would be able to confirm the following :-
In a mobile network scenario with thousands of IoT devices
On our radius servers, we've been noticing a lot of 0-byte sessions on our databases and upon investigation, we've seen the following behaviour :-
Authentication Request Received < Access Accept sent back Accounting Start Packet Received with a Acct-Session-Id < Acknowledgement sent back Interim Accounting Packet Received - This time with a different Acct-Session-Id for the same connection ** At this point, things start going bad as we are not able to update the original DB entry created with the Acct Start Packet, since the Acct-Session-Id differs between the packet received in the Accounting Start Packet and the Interim Accounting Packet.
This results in a 0-session entry in the DB for the Accounting Start Packet entry as a new entry is written into the DB based on the new Acct-Session-Id received in the Interim Accounting packet.
Any subsequent packets received with a different Acct-Session-Id, results in writing a new DB entry when the Interim Accounting Packet is received.
We queried this with the upstream provider, and they advised that the 3GPP-NSAPI number changes when packets are received and they claim that the Acct-Session-Id on their side would change based on the 3GPP-NSAPI value that could (and in most cases) changes.
< Acknowledgement Sent back
From what I've been reading, The Acct-Session-Id should remain constant for the entire PDP context/session, even when the NSAPI changes because the Acct-Session-Id is meant to uniquely identify the entire user session. NSAPI changes are considered sub-sessions within the main PDP context and keeping the same Acct-Session-Id helps maintain session continuity for billing and tracking purposes, which is exactly our use case for accounting which is not working as expected.
Any thoughts and insights would be appreciated if someone faced a similar situation.
Many thanks, Gabriel - List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html
On 2025/02/24 09:05, Gabriel Marais wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Just in case, I have seen at least one instance where there is an Acct-Multi-Session-Id that is stable, and Acct-Session-Id is not. Worth a check, you never know given how many manufacturers coders seem to have limited ability to read a standard and implement what it says. -- A.Winfield. From: Freeradius-Users <freeradius-users-bounces+alister.winfield=sky.uk@lists.freeradius.org> on behalf of Gabriel Marais <gabriel.j.marais@gmail.com> Date: Monday, 24 February 2025 at 07:06 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: [EXTERNAL] NSAPI changes Acct-Session-Id from upstream provider Hi Guys This might be off topic but I was wondering if someone with more knowledge than me, would be able to confirm the following :- In a mobile network scenario with thousands of IoT devices On our radius servers, we've been noticing a lot of 0-byte sessions on our databases and upon investigation, we've seen the following behaviour :-
Authentication Request Received < Access Accept sent back Accounting Start Packet Received with a Acct-Session-Id < Acknowledgement sent back Interim Accounting Packet Received - This time with a different Acct-Session-Id for the same connection
** At this point, things start going bad as we are not able to update the original DB entry created with the Acct Start Packet, since the Acct-Session-Id differs between the packet received in the Accounting Start Packet and the Interim Accounting Packet. This results in a 0-session entry in the DB for the Accounting Start Packet entry as a new entry is written into the DB based on the new Acct-Session-Id received in the Interim Accounting packet. Any subsequent packets received with a different Acct-Session-Id, results in writing a new DB entry when the Interim Accounting Packet is received. We queried this with the upstream provider, and they advised that the 3GPP-NSAPI number changes when packets are received and they claim that the Acct-Session-Id on their side would change based on the 3GPP-NSAPI value that could (and in most cases) changes. < Acknowledgement Sent back
From what I've been reading, The Acct-Session-Id should remain constant for the entire PDP context/session, even when the NSAPI changes because the Acct-Session-Id is meant to uniquely identify the entire user session. NSAPI changes are considered sub-sessions within the main PDP context and keeping the same Acct-Session-Id helps maintain session continuity for billing and tracking purposes, which is exactly our use case for accounting which is not working as expected.
Any thoughts and insights would be appreciated if someone faced a similar situation. Many thanks, Gabriel - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -------------------------------------------------------------------- This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to phishing@sky.uk. Thank you -------------------------------------------------------------------- Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
On Feb 24, 2025, at 7:01 AM, Winfield, Alister (Senior Solutions Architect) via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Just in case, I have seen at least one instance where there is an Acct-Multi-Session-Id that is stable, and Acct-Session-Id is not.
That's actually required by RFC 2866 Section 5.11, which defines Acct-Multi-Session-Id : This attribute is a unique Accounting ID to make it easy to link together multiple related sessions in a log file. Each session linked together would have a unique Acct-Session-Id but the same Acct-Multi-Session-Id. This behavior makes no sense to me. What would be sane is having Acct-Session-ID as stable, so you have a common session identifier, even if Acct-Multi-Session-ID doesn't exist. Instead, you have to check for Acct-Multi-Session-ID. If it exists, it's the stable session identifier. Otherwise, Acct-Session-ID is the stable session identifier. And then I'm
Worth a check, you never know given how many manufacturers coders seem to have limited ability to read a standard and implement what it says.
I could forgive incompetence and inexperience. What I find baffling is when there are clear intentions to ship idiotic code. Alan DeKok.
On Mon, Feb 24, 2025 at 2:53 PM Alan DeKok <aland@deployingradius.com> wrote:
On Feb 24, 2025, at 7:01 AM, Winfield, Alister (Senior Solutions Architect) via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Just in case, I have seen at least one instance where there is an Acct-Multi-Session-Id that is stable, and Acct-Session-Id is not.
That's actually required by RFC 2866 Section 5.11, which defines Acct-Multi-Session-Id :
This attribute is a unique Accounting ID to make it easy to link together multiple related sessions in a log file. Each session linked together would have a unique Acct-Session-Id but the same Acct-Multi-Session-Id.
This behavior makes no sense to me. What would be sane is having Acct-Session-ID as stable, so you have a common session identifier, even if Acct-Multi-Session-ID doesn't exist.
It would have made things a lot easier if Acct-Session-Id was the stable. In this case, Acct-Multi-Session-Id makes sense, but we are not getting that attribute in any of our radius packets which makes it even harder to keep track of session data usage and creates even more overhead on the amount of DB entries purely because now, we have no way to link same session data together.
Instead, you have to check for Acct-Multi-Session-ID. If it exists, it's the stable session identifier. Otherwise, Acct-Session-ID is the stable session identifier.
And then I'm
Worth a check, you never know given how many manufacturers coders seem to have limited ability to read a standard and implement what it says.
I could forgive incompetence and inexperience. What I find baffling is when there are clear intentions to ship idiotic code.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (5)
-
Alan DeKok -
Conrad Classen -
Gabriel Marais -
Matthew Newton -
Winfield, Alister (Senior Solutions Architect)