NSAPI changes Acct-Session-Id from upstream provider

Alan DeKok aland at deployingradius.com
Mon Feb 24 12:31:10 UTC 2025


On Feb 24, 2025, at 4:56 AM, Matthew Newton via Freeradius-Users <freeradius-users at 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-05#name-a-comment-on-specifications

> Yeah, quite. The behaviour needs fixing or the kit needs throwing in the bin and replacing with something sane.

  Yup.

  Alan DeKok.



More information about the Freeradius-Users mailing list