[asterisk-bugs] [JIRA] (ASTERISK-16867) [patch] Hold/Unhold not possible with SIP using SRTP

Alexander Traud (JIRA) noreply at issues.asterisk.org
Thu Jan 3 06:44:47 CST 2019


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

Alexander Traud edited comment on ASTERISK-16867 at 1/3/19 6:44 AM:
--------------------------------------------------------------------

The [code change|https://github.com/asterisk/asterisk/commit/085b7b212a1ff3a343b16a7b803527f2afd6ac1f] disabled the [Replay Protection|http://tools.ietf.org/html/rfc3711#section-3.3.2] of sRTP in general.

Unfortunately, I cannot see attachments of this issue report. Were they lost with the transition from Mantis to Jira? Because of this, I cannot look into a packet trace to analyze the actual cause of this issue. Furthermore, I do not have a Grandstream HT502 or Grandstream HT503 to test the latest firmware. However, with a [VTech VDP600|https://businessphones.vtech.com/pd/2546] (Snom M200 SC, Alcatel IP2215 aka ATLINKS IP2215), I saw issues with the sequence number of the media packets (RTP-SEQ): It resets the stream because of a SIP Session Timer. This is a software bug of this device. By this, a new RTP-SEQ is randomly chosen as starting point. If a lower RTP-SEQ was taken, Asterisk resets its stream as well. Because of this, the two match again and the call/audio continues.

This code change killed the Replay Protection and even worse allows an attacker to turn down long-lasted calls (when the RTP-SEQ wrapped from 0xffff to 0x0, libSRTP increased a roll-over counter sRTP-ROC internally; Asterisk resets the stream, which resets the ROC to 0, and therefore the correct audio is not authenticated anymore).

In the past, Asterisk has seen several enhancements when it comes to sRTP, like ASTERISK-20194 which handles re-INVITEs with new key material. Therefore, it is questionable whether this change is still needed nowadays. With my device, it is a software bug which cannot be repaired by Asterisk (if not a lower but a higher RTP-SEQ was taken randomly, Asterisk does not reset its stream).

I attached a patch which disables this code change and therefore re-enables Replay Protection. Not sure if I have the time, to test all my devices against this. We have three options:
a) leave the code as is; concerned users applies my patch manually
b) remove the code and add a statement to the document CHANGES
c) add a new configuration setting to change state of Replay Protection at runtime in general (perhaps to RTP.conf) or on a peer level (\[pj\]sip.conf).


was (Author: traud):
The [code change|https://github.com/asterisk/asterisk/commit/085b7b212a1ff3a343b16a7b803527f2afd6ac1f] disabled the [Replay Protection|http://tools.ietf.org/html/rfc3711#section-3.3.2] of sRTP in general.

Unfortunately, I cannot see attachments of this issue report. Were they lost with the transition from Mantis to Jira? Because of this, I cannot look into a packet trace to analyze the actual cause of this issue. Furthermore, I do not have a Grandstream HT502 or Grandstream HT503 to test the latest firmware. However, with a VTech VDP650 (Snom M200 SC, Alcatel IP2215 aka ATLINKS IP2215), I saw issues with the sequence number of the media packets (RTP-SEQ): It resets the stream because of a SIP Session Timer. This is a software bug of this device. By this, a new RTP-SEQ is randomly chosen as starting point. If a lower RTP-SEQ was taken, Asterisk resets its stream as well. Because of this, the two match again and the call/audio continues.

This code change killed the Replay Protection and even worse allows an attacker to turn down long-lasted calls (when the RTP-SEQ wrapped from 0xffff to 0x0, libSRTP increased a roll-over counter sRTP-ROC internally; Asterisk resets the stream, which resets the ROC to 0, and therefore the correct audio is not authenticated anymore).

In the past, Asterisk has seen several enhancements when it comes to sRTP, like ASTERISK-20194 which handles re-INVITEs with new key material. Therefore, it is questionable whether this change is still needed nowadays. With my device, it is a software bug which cannot be repaired by Asterisk (if not a lower but a higher RTP-SEQ was taken randomly, Asterisk does not reset its stream).

I attached a patch which disables this code change and therefore re-enables Replay Protection. Not sure if I have the time, to test all my devices against this. We have three options:
a) leave the code as is; concerned users applies my patch manually
b) remove the code and add a statement to the document CHANGES
c) add a new configuration setting to change state of Replay Protection at runtime in general (perhaps to RTP.conf) or on a peer level (\[pj\]sip.conf).

> [patch] Hold/Unhold not possible with SIP using SRTP
> ----------------------------------------------------
>
>                 Key: ASTERISK-16867
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-16867
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/SRTP
>            Reporter: Bernhard S
>              Labels: patch
>         Attachments: replay_protection.patch, res_srtp_unhold.patch
>
>
> 2 phones connected with SIP on Asterisk. Both are configured with SRTP. Call from phone A to phone B. Then A press "hold" and after 20 seconds, A press unhold. Then there is no voice from A to B and also no voice from B to A. On the console I get the error:
> res_srtp.c:338 ast_srtp_unprotect: SRTP unprotect: replay check failed (index too old)
> If the hold time is less (e.g. not 20 seconds but 2 seconds) it does _sometimes_ work.



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



More information about the asterisk-bugs mailing list