[cisco-nas] >255 radius requests = bug?

[Tassos Chatzithomaoglou]

Hi Dennis,

As it seems, you're watching my tac case too? ;-)


Dennis Peng wrote:
> achatz at forthnet.gr [achatz at forthnet.gr] wrote:
> 
>>The scenario
>>-------------
>>LNS terminating 500+ adsl users.
>>The tunnel goes down/up, so all users are trying again to authenticate simultaneusly.
>>Radius server isn't able to handle all those requests, so some udp packets are dropped.
>>Router has to retransmit all these requests that aren't replied.
>>Since unique-id is only 8 bits, we can have 255 concurrent unique access-requests.
>> 
>>Router sends a access-request using an id and at the same time the radius is using the same id 
>>in order to reply to the router for a previous request (which also had this id). 
>>So the router thinks that this reply from the radius is about the last request, 
>>but this is actually for the previous request (both had the same  id).
> 
> 
> This cannot happen. Each Access-Request the router sends has a random
> number in the Request-Authenticator. When the RADIUS server responds,
> the Message-Authenticator contains a hash of the RADIUS reply along
> with Request-Authenticator and other fields. If the router has more
> then one transaction outstanding for a particular transaction id, it
> will try to decrypt the response packet with each of the outstanding
> Request-Authenticator's which used that transaction id. Only the
> "correct" Access-Request would have the right Request-Authenticator to
> decrypt the packet. So you may see "decrypt" failures in the debug
> logs, however, eventually we will match to the right one.
> 

Although i did saw some decrypt failures, the wrong user (who was not supposed to login, 
since radius was rejecting him) did get the access-accept attributes (which belonged to 
another user!!!) and so he logged in.




> 
>>The result
>>----------
>>A user which is not allowed to login, will be authenticated normally and 
>>will get all radius attributes of another user (who is allowed to login)!!!
> 
> 
> The problem you are seeing may be a result of low memory. Your logs
> show a failure to insert attributes in the RADIUS database, which is
> usually caused by a lack of free memory. Have you looked at "show mem"
> after one of these events to see if the amount of free memory was low?
> 

I have never seen it fall under 70/15 MB....so can i suppose we don't have a problem here?


> 
>>Can the above result be considered a bug from router's side?
>>Is this the way radius authentication is supposed to work?
> 
> 
> Because the transaction id number space is so limited (256 as you
> mention), we extended our scalability by the use of multiple source
> ports in later code so that bulk transactions with the RADIUS server
> work better. Depending on what version of code you are running, this
> may be on by default. In most recent code, we try to maintain backward
> compatibility, so you have to configure the command "radius-server
> source-ports extended". We will use source ports in the range from
> 21645 to 21844 in that case.
> 
> Dennis
> 
> 
>>If yes, how can something like this be considered secure?
> 

Since i'm already discussing (through my case) it with Irfan and cisco-nas guys are also 
part of the escalation team (quite a relief...), i believe it would be better to stop the 
mails in this list and continue through my case. Glad to see you Dennis ;-)

> 
>>_______________________________________________
>>cisco-nas mailing list
>>cisco-nas at puck.nether.net
>>https://puck.nether.net/mailman/listinfo/cisco-nas
> 
> 
> 

-- 
***************************************
       Chatzithomaoglou Anastasios
Network Design & Development Department
              FORTHnet S.A.
          <achatz at forthnet.gr>
***************************************