[asterisk-dev] [Fwd: Re: [svn-commits] kpfleming: branch 1.4 r81442- /branches/1.4/channels/chan_sip.c]

[Raj Jain]

I'm assuming that the discussion below is about how to reject an INVITE that
contains a digest response to a previous challenge and the response is not
acceptable to Asterisk i.e. the following scenario:

   UAC        Asterisk
    |             |
    |-- INVITE -->|
    |<--- 401 ----|
    |---- ACK --->|
    |-- INVITE -->|
    |<--- ??? ----|   <== What response code to use here?
    |---- ACK --->|


The reason I stated this assumption is because, clearly the initial INVITE
that does not carry a digest response in it but needs to be authenticated
will have to be rejected with a 401 (so the UAC knows that it has to present
its credentials). So, the question would be that once the Asterisk knows
that a UAC does not have the right credentials then how to prevent the UAC
from going into an INVITE-401 loop. I'm pretty sure that's the question that
was asked (just wanted to confirm this for my own understanding).

The interesting thing about this question is that according to RFC 3261
(section 8.2.7), a UAS processes an INVITE-401 completely stateless fashion
(even a transaction state is not maintained). This is a security feature to
prevent DoS attacks on the UAS. So, in RFC 3261's opinion if a UAC goes into
an INVITE-401 infinite then that loop is fine. They solved the problem by
making the UAS stateless.  

That said, there are a couple of things that can be done in Asterisk to
solve this problem (I'm getting into implementation details, which have
probably already been addressed in the branch in the email's subject line).
First, the back-to-back INVITE-401 failures can be tracked in
sip_user/sip_peer structs and that state can be used to reject the 2nd
INVITE with a 403. The second option is that we know that whether an INVITE
carries our nonce in it or not. If it does but the password doesn't match
then the INVITE can be rejected with a 403. These behaviors should obviously
be configurable and turned-off by default.

I'd agree that 403 is the most appropriate response code in this case. If we
want to send back some extra piece of information to the UAC's human user,
then we can use reason phrase for that (e.g. "403 Invalid Credentials"). 

Thanks,
Raj 

 

> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com 
> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of 
> Kevin P. Fleming
> Sent: Thursday, September 06, 2007 5:51 PM
> To: Asterisk Developers Mailing List
> Subject: [asterisk-dev] [Fwd: Re: [svn-commits] kpfleming: 
> branch 1.4 r81442- /branches/1.4/channels/chan_sip.c]
> 
> Olle and I have been having a conversation regarding this 
> commit, and I'd like to solicit comments from the community 
> on whether they feel we should add back in the 'send 401 
> forever and ever and ever' behavior with a configuration 
> option (defaulting to off), and if so, what should the name 
> of that option be?
> 
> > Olle E Johansson wrote:
> 
> The RFC says
> 
> "21.4.4 403 Forbidden
> The server understood the request, but is refusing to fulfill it.
> Authorization will not help, and the request SHOULD NOT be repeated."
> 
> In this case, proper authorization will help. If we send 403, 
> we're telling the phone to stop trying sending INVITE to us 
> regardless of authorization, time of day, phase of the moon 
> and amount of youtube traffic in your network. That's not 
> really what you want.
> 
> In another part of the RFC, it actually states another use 
> for an INVITE scenario. If the callee refuses to answer, like 
> pressing the red button on your cell phone, the RFC 
> recommends sending 403. I believe that's a big contradicting, 
> but - hey - we're talking about the SIP rfc
> :-) (or they might hint that this is a good way of adding a 
> caller, ex- girlfriend, to a blacklist)...
> 
> But I agree, with a configuration option, we can send 403 to 
> stop unneeded traffic. The phone needs a reconfiguration, so 
> we might as well tell it to go away until it has sorted out 
> it's life and approach us with a new, propably rebooted, attitude.
> 
> Cheers,
> /O
> 
> --
> Kevin P. Fleming
> Director of Software Technologies
> Digium, Inc. - "The Genuine Asterisk Experience" (TM)
> 
> _______________________________________________
> 
> Sign up now for AstriCon 2007!  September 25-28th.  
> http://www.astricon.net/ 
> 
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev