Hello everybody,
I am using SER 0.9.3 and freeRADIUS 1.0.4 with digest authentication.
I am having problems when users with invalid credentials (wrong username or password) try to register to SER. The same thing happens when I insert some records to usergroup table as Reject type in Radius DB. SER is becoming unfunctional in this case in our system. It cannot perform registration and cannot make call for even valid subscribers.
SIP clients with invalid credentials try to register and send REGISTER messages continuously. A SIP client sends 20 request/min and there are 7-8 clients available at the moment. i.e. it is not a big traffic. But every client is tried to be authenticated using digest during registration and at the beginning of the call.
In such a case, SER slows down very much. Retransmissions starts and SER becomes unfunctional.
Did anyone experienced this problem? Do you have any idea why does it happens?
Thanks in advance.. Regards,
Tulay Sazak NGN, Borusan Telekom
--------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less
Hi Tulay!
For REGISTER requests, you should immediately reply with 100 Trying to avoid retransmissions of REGISTER requests.
sl_send_reply("100","Stop retransmission");
The second thing is to find out why the authentication takes that much time. If the username/password is wrong, the Radius server should reply with Authentication-Reject, thus the sip proxy should reply with 401/403. This should not need more time then the reply for a successful authentication.
I suggest using "ngrep -t port 5060 or port 1812" to watch the whole authentication signaling. Analyze were the delay occours and dig into the problem.
klaus
tulay sazak wrote:
Hello everybody,
I am using SER 0.9.3 and freeRADIUS 1.0.4 with digest authentication.
I am having problems when users with invalid credentials (wrong username or password) try to register to SER. The same thing happens when I insert some records to usergroup table as Reject type in Radius DB. SER is becoming unfunctional in this case in our system. It cannot perform registration and cannot make call for even valid subscribers.
SIP clients with invalid credentials try to register and send REGISTER messages continuously. A SIP client sends 20 request/min and there are 7-8 clients available at the moment. i.e. it is not a big traffic. But every client is tried to be authenticated using digest during registration and at the beginning of the call.
In such a case, SER slows down very much. Retransmissions starts and SER becomes unfunctional.
Did anyone experienced this problem? D o you have any idea why does it happens?
Thanks in advance.. Regards,
Tulay Sazak NGN, Borusan Telekom
Yahoo! DSL <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.co...
Something to write home about. Just $16.99/mo. or less
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Klaus Darilion said:
If the username/password is wrong, the Radius server should reply with Authentication-Reject, thus the sip proxy should reply with 401/403. This should not need more time then the reply for a successful authentication.
depends on the radius server and its reject delay. it would be a good idea to have reejct delay built in to ser so that it would apply no matter what kind of authentication is in question.
-- juha
On 02-12-2005 11:26, Juha Heinanen wrote:
Klaus Darilion said:
If the username/password is wrong, the Radius server should reply with Authentication-Reject, thus the sip proxy should reply with 401/403. This should not need more time then the reply for a successful authentication.
depends on the radius server and its reject delay. it would be a good idea to have reejct delay built in to ser so that it would apply no matter what kind of authentication is in question.
Alternatively you can block excessive traffic using pike module. SER could just drop incoming messages if the amount of traffic exceeds some threshold, and send back "4xx Too Much Traffic" once in a while to notify the user that he should slow down/replace the ua. Once in a while pike would let the icoming message through.
Jan.