Re: [Bug-gnu-radius] patchinfo: 2169 Send authentication reject in case of a malformed user

[Maurice Makaay]

Hi,

> Yes, there is. Very often a malformed username is due to some
> NAS IOS problem, for example while using a certain buggy NAS
> I've often observed the beginning of a PPP session in the User-Name
> attribute. In these cases there is no use sending back the reply.
> I guess it is better to make it configurable.

There's indeed no real use in sending back a reply (since the NAS is 
possibly not expecting a reply), but there is as well no harm in 
it I think. Neglecting to send back a reject on malformed usernames
causes every single NAS which is handling radius correctly but which
is merely passing on incorrect usernames (e.g. "m,makaay" instead of 
"m.makaay") to start retransmitting the radius request to the radius
server. After a while it will even decide that the radius server is
not responding and will (if available) switch to a fail-over radius
server which will display the same behaviour. In the end, the NAS has
been retransmitting a number of authentication requests, has not
received any replies and will (after a considerable delay) deny access
to the user. 

So, looking at this behaviour, what would be the drawback of returning
an authentication reject packet to the NAS in case of a malformed 
username? It can't be the packet itself, because in the end it will
be much cheaper to send back one reject packet than to keep processing
malformed users from the NAS.

If desirable, I can make this into a configuration option. I would
however plead for making rejecting the default behaviour for it,
because I think that there are more buggy users than buggy NAS-es out
there... 

With kind regards,

-- Maurice Makaay