[asterisk-bugs] [JIRA] (ASTERISK-29013) res_pjsip: Asterisk doesn't stop sending invites (with auth) on 407 replies

[Sebastian Damm (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=251570#comment-251570 ] 

Sebastian Damm commented on ASTERISK-29013:
-------------------------------------------

I managed to reproduce the scenario. When the nonce of the 407 doesn't change, Asterisk indeed stops re-sending the INVITEs after two attempts with the message you also got. However, when the nonce changes with each 407, Asterisk keeps sending INVITEs responding to the new challenge. 

And, if you let it running long enough, Asterisk will consume more and more memory. 

I have created a docker setup with two sipp instances calling each other, the called side answering with 407 for 10 times before finally replying with 404. Asterisk sends out a new INVITE for each 407 received.

> res_pjsip: Asterisk doesn't stop sending invites (with auth) on 407 replies
> ---------------------------------------------------------------------------
>
>                 Key: ASTERISK-29013
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29013
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip, Resources/res_pjsip_authenticator_digest
>    Affects Versions: 17.6.0
>         Environment: Debian Buster, Asterisk Package built from sources
>            Reporter: Sebastian Damm
>            Assignee: Sebastian Damm
>            Severity: Minor
>
> We have the following setup. (From our pjsip.conf)
> [domain.de](generic_endpoint)
> auth=domain_internal_auth
> outbound_auth=domain_internal_auth
> from_domain=domain.de
> outbound_proxy=sip:sip.domain.net\;lr
> aors=domain.de_aor
> [domain.de_aor]
> type=aor
> contact=sip:domain.de
> outbound_proxy=sip:sip.domain.net\;lr
> [domain_internal_auth]
> type=auth
> auth_type=userpass
> username=happyuser
> password=reallysecret
> This endpoint is used to reach our registered customer devices, with a Kamailio proxy in between. Now when we send out a call through this endpoint, the proxy server asks for Auth. Asterisk responds to the challenge, and normally the call goes through. But we have a client device (an Asterisk server) behind the proxy server asking for authentication, too. (Of course, we don't know any password for this client device.)
> In that scenario, Asterisk17 does not stop sending INVITEs toward the proxy. When the first 407 is received, an Proxy-Authorizationheader for authenticating against the proxy server gets created, and when the second 407 is received, Asterisk sends out the next INVITE with two Proxy-Authorization headers.
> {{Proxy-Authorization: Digest username="happyuser", realm="domain.de", nonce="Xxl+ZF8ZfTg2/dTjNjcsTCYGI3Z+f85d", uri="sip:004926439482507 at domain.de", response="cc3cdb70fa0451b51aa8cbf9ccfb6426"}}
> {{Proxy-Authorization: Digest username="happyuser", realm="asterisk", nonce="545e619d", uri="sip:004926439482507 at domain.de", response="66400b176d5c9d2c3f0aad26d3683391", algorithm=MD5}}
> After 30 seconds, the caller cancels the call, Asterisk sends out a CANCEL request, which - again - gets rejected with a 407 by the end user device. Asterisk does not re-send the CANCEL message, but does not stop sending out the INVITE requests. And this goes on forever. 
> We have only noticed this behavior, because we saw a massive amount of memory getting used by the Asterisk process. And we didn't send any new traffic to Asterisk and {{core show channels}} didn't show any calls anymore, the INVITEs to this device kept on going.
> This could result in a DOS, if you know the setup and can setup a scenario like this and send a lot of calls through this setup. Multiple calls result in Asterisk using all of the available memory twice as fast.
> In my opinion, Asterisk should stop sending out INVITEs after receiving a maximum of 3 407 responses. Our old Asterisk11 boxes behave that way, when handling calls to the same customer device. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)