[asterisk-dev] Improper (?) use of SIP 403 to reject REGISTER for bad auth

[Nathan Anderson]

All,

Not sure if this is the appropriate place to discuss; if not, please accept my apology in advance and redirect me to the proper forum.  I wasn't sure I should file a JIRA issue before floating this past somebody, and 'asterisk-users' didn't seem like the right fit either.

We are an ISP and ITSP, and we use Asterisk (1.8 LTS) as a SIP registrar and call feature server.  We use the ARA (realtime arch.) to implement a database-driven list of peers and their authentication credentials.  We also have a few customers using Asterisk as a PBX that we provide SIP trunking service to.

This past week, we had a network event on our side that briefly caused reachability problems between our Asterisk server and the database server.  We quickly corrected the issue.  During this time, though, a customer of ours using Asterisk attempted to re-REGISTER, and was refused with "SIP/2.0 403 Forbidden (Bad auth)".  Despite the fact that their Asterisk instance was configured to continually retry registration (registerattempts=0), upon receiving the 403 code, their PBX completely stopped making further attempts.  Unaware that there was a problem (because everything was fine on our end), we ended up handing them a 3-hour outage that was only over when they contacted us and we issued a 'sip reload' on their side (something, I will argue, that we shouldn't have had to do).

Not good.

Of course, I did some research after this, and discovered that having the UAC (in this case, the customer's Asterisk PBX) "cease and desist" upon recepit of SIP 403 does, in fact, sound like the proper behavior, according to RFCs.  The question I wish to raise before the house now, though, is whether Asterisk, when acting in the role of a SIP registrar, is responding correctly to what it perceives to be an invalid auth attempt.  There is evidence to suggest that the Asterisk UAC responded correctly to the 403, but that the Asterisk UAS was out of line in issuing that 403 to begin with in response to an invalid auth; see (e.g.) SIP-Implementors post https://lists.cs.columbia.edu/pipermail/sip-implementors/2004-August/006960.html

If a breakdown or misconfiguration that happens on our side temporarily causes our Asterisk UAS to fail to authenticate valid clients of ours, I think it is completely unreasonable to expect our clients to reset their gear on their side before they start working again.  So if SIP 403 causes this behavior in standards-compliant UACs, and if there is evidence to suggest that SIP 403 is not the proper response code to a REGISTER request that fails authentication anyway, then I submit that the response code generated by Asterisk in such circumstances is not appropriate should be changed.

Although we are using 1.8, I have checked the latest release of 11, and it appears to still be doing the same thing (chan_sip.c, register_verify(), 'case AUTH_SECRET_FAILED').

Right now, to avoid such a scenario from happening in the future, my options are to either patch up and rebuild Asterisk on our side to respond differently to failed SIP REGISTER attempts, or to encourage our Asterisk-using customers (many of whom have their PBX maintained by us anyway) to use a build of Asterisk on their side that implements the patch from JIRA issue 17138 (https://issues.asterisk.org/jira/browse/ASTERISK-17138).

Comments?

-- 
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com