[Home]

Summary:ASTERISK-16867: [patch] Hold/Unhold not possible with SIP using SRTP
Reporter:Bernhard S (bernhards)Labels:patch
Date Opened:2010-10-25 03:31:36Date Closed:2011-05-13 13:06:29
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/SRTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) replay_protection.patch
( 1) res_srtp_unhold.patch
Description: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.
Comments:By: Bernhard S (bernhards) 2010-10-27 04:06:16

Please find attached a patch. The patch does simply re-establish the SRTP session and add all the policies to it again. Maybe just a "try" to show how the real fix should look like.

By: frank koster (notthematrix) 2010-11-04 12:19:24

Installed the patch ,
see if it also iliminates certain whitenoice carbage situation in thge middele of a call....
Because If I remeber correctly , internet hickups  can put asterisk in (hold)
for a very short wile and comming back when RTP flow is restored...

Using granstream ht-50x in (TCP)TLS / SRTP forced..



By: Bernhard S (bernhards) 2010-12-01 02:50:41.000-0600

Patch does work for more than a month on our system.

By: Digium Subversion (svnbot) 2011-05-13 13:04:51

Repository: asterisk
Revision: 318919

U   branches/1.8/res/res_srtp.c

------------------------------------------------------------------------
r318919 | bbryant | 2011-05-13 13:04:51 -0500 (Fri, 13 May 2011) | 10 lines

This patch fixes an issue with SRTP which makes HOLD/UNHOLD impossible when too
much time has passed between sending audio.

(closes issue ASTERISK-16867)
Reported by: bernhardsi
Patches:
     res_srtp_unhold.patch uploaded by bernhards (license 1138)
Tested by: bernhards, notthematrix


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=318919

By: Digium Subversion (svnbot) 2011-05-13 13:06:29

Repository: asterisk
Revision: 318920

_U  trunk/
U   trunk/res/res_srtp.c

------------------------------------------------------------------------
r318920 | bbryant | 2011-05-13 13:06:28 -0500 (Fri, 13 May 2011) | 16 lines

Merged revisions 318919 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
 r318919 | bbryant | 2011-05-13 14:04:50 -0400 (Fri, 13 May 2011) | 10 lines
 
 This patch fixes an issue with SRTP which makes HOLD/UNHOLD impossible when too
 much time has passed between sending audio.
 
 (closes issue ASTERISK-16867)
 Reported by: bernhardsi
 Patches:
       res_srtp_unhold.patch uploaded by bernhards (license 1138)
 Tested by: bernhards, notthematrix
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=318920

By: Alexander Traud (traud) 2019-01-03 06:41:55.800-0600

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).