Skip to content
Alan DeKok edited this page Aug 23, 2023 · 23 revisions

Issues and Fixes 2

Because RFC5080 was not enough.

This Wiki is an "ad hoc" place-holder for issues that people find with RADIUS implementations.

Please request access via the IETF RADEXT WG mailing list

Issues

  • The NAS repeatedly sends accounting start packets when the RADIUS server isn't available. They fail the Start after retransmission interval * retransmission count. Every 15 minutes they try and resend the start packet instead of switching to interims.

  • Every time they retransmit the start packe, the Event-Timestamp is updated to be the current time, so you have no idea when the subscriber came online.

  • Acct-Delay-Time is a garbage value, it starts off at zero, and then seems to cycle through some fixed numbers, going up to millions of seconds.

  • Acct-Input-Octets/Acct-Output-Octets have garbage values. Doing some math, the average packet size is 2.7MB

  • When sending a Disconnect-Request, the re-authentication occurs several minutes after the packet has been received. The reauthenticationg is driven by DHCP traffic, so this is perhaps not terrible. What'is not expected is that the accounting start packet is then delayed by several minutes after the Access-Accept.

  • The NAS uses a global timer to send Interim-Updates. Which means they send updates for every subscriber at the same time instead of staggering them, so it sends 10s of thousands of interims at the same time, and then nothing for 15 minutes.

  • A different User-Name value is used for Access-Requests and Accounting-Requests so it is not possible to tie them together. Reading 2866 etc. shows that this behavior isn't forbidden, likely because no one thought an implementation would be this bizarre.

  • The NAS-Identifier contains a copy of the NAS-Port-Id. Which means that there is real NAS-Identifier sent in Access-Requests.

  • NAS-Port-ID values in Access-Requests and Accounting-Requests are different.

  • User-Name in CoA truncated at 43 chars.

  • Sending Class or User-Name in Access-Accepts results in authentication failing.

  • As a result, any Class/User-Name not echoed in Accounting-Requests

  • RADIUS dynauth server that returned NAK when Message-Authenticator was in a dynauth request. The attribute is not required, but these kinds of small variations make it hard to create dynauth messages in multivendor systems.

  • Incorrect use of zero-length (empty) attributes. For example, clients that support RFC 7268 EAP-Key-Name and RFC 4372 Chargeable-User-Identity must use a single all-zero bits octet to request action from the server. Some clients use a zero-length value instead. This is forbidden by the respective RFCs and RFC 2865 string type definition.

  • when should the NAS send the accounting start? 2866 doesn't define any way to know when a session starts.

Clone this wiki locally