[Home]

Summary:ASTERISK-16898: SRTP unprotect: authentication failure when RTP sequence number switches from 65535 -> 0
Reporter:Marcello Ceschia (marcelloceschia)Labels:patch
Date Opened:2011-01-19 06:53:30.000-0600Date Closed:2017-09-21 11:37:19
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/SRTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) srtpROC-Debug_for_Asterisk11.patch
( 1) srtpROC-LE_for_Asterisk11.patch
( 2) srtpROC-LE_for_Asterisk13.patch
( 3) srtpROC-LE_for_Asterisk16.patch
( 4) srtpROC-LE_for_libsrtp1.4.5.patch
( 5) srtpROC-LE_for_libsrtp1.5.x.patch
( 6) srtpROC-LE_for_libsrtp1.6.x.patch
( 7) srtpROC-LE_for_libsrtp2.0.x.patch
( 8) srtpROC-LE_for_libsrtp2.1.x.patch
( 9) srtpROC-LE_for_libsrtp2.2.x.patch
(10) srtpROC-LE_for_libsrtp2.3.x.patch
Description:{noformat}
[Jan 19 09:29:34] WARNING[9825] res_srtp.c: SRTP unprotect: authentication failure
{noformat}

{noformat}
Useragent    : Nokia RM-530 052.005
Prim.Transp. : TLS
{noformat}

*ADDITIONAL INFORMATION*

Depending on the initialze sequence number, the audio stream will become one way.
I did several tests with the same result always.
Comments:By: Michi (michaesc) 2011-05-25 09:14:59

This isn't limited to Nokia user agents. My test of SRTP using SDES over TLS led to the same failure (one way audio) with a Snom 8.4.31 user agent. The test lasted about 1 1/2 hours before the one way audio began.

By: Aaron Stover (webghost) 2011-11-11 14:57:19.320-0600

Erin, could you elaborate on the relationship to SWP-2945? My company is looking to completely switch to Asterisk but this SRTP problem is causing us some heartburn.

By: Richard Mudgett (rmudgett) 2011-11-11 18:42:46.923-0600

SWP-2945 is an internal planning project for prioritizing issues.

By: Aaron Stover (webghost) 2011-11-12 13:15:59.800-0600

Understood. As this is a big bug for my company, I'm going to spend some time trying to debug it. I'm not asking anyone to spend any significant amount of time on this (I completely understand that the project already has its priorities worked out) but if there's anyone out there that has taken some time to look at this issue, it would be great if they could share their thoughts. It might help point me in the right direction. Thanks!

By: Marcello Ceschia (marcelloceschia) 2011-11-14 06:51:01.963-0600

this issue is in libsrtp.
Nokia increments the roc when reaching the start sequence number. After 20 minutes of unprotect error audio will be fine for some minutes.


By: Olle Johansson (oej) 2013-09-02 10:18:22.913-0500

ANy updates to this issue?

By: Alexander Traud (traud) 2014-05-06 03:53:24.633-0500

Every voice media packet (RTP) is tagged with a sequence number (SEQ) from 0 to 65535 = 0xffff. With sRTP, a roll-over counter (ROC) increments, every time when SEQ=0 is reached. This ROC is not exchanged over the network, but calculated by both parties (here: Nokia and libsrtp). This ROC is used to create some parts of the RTP packet, for example the authentication tag. Therefore, the one-way voice because the packet cannot be decoded anymore.

All [Nokia Symbian/S60|http://developer.nokia.com/community/wiki/VoIP_support_in_Nokia_devices#Support_in_Symbian.2FS60_devices] mobile phones use a little-endian ROC (ROC-LE). [RFC 3711|http://tools.ietf.org/html/rfc3711#section-3.3.1] and [libsrtp|https://github.com/cisco/libsrtp] expect a network-order ROC (big-endian). Because these phones do not get firmware updates anymore—some are from 2007—we have to patch what is patchable: The attached srtpROC-LE_for_Asterisk.patch enables chan_sip to detect Nokia Symbian/S60 devices. Then, libsrtp is notified. The srtpROC-LE_for_libsrtp.patch creates RTP packets with the expected ROC. Consequently, after applying these two patches, Asterisk/libsrtp remain compatible to existing VoIP phones and are enhanced to support Nokia Symbian/S60.

I patched Asterisk as usual. For libsrtp, I used the following commands to patch libsrtp, in Ubuntu 14.04:
{{sudo apt-get build-dep srtp}}
{{apt-get source srtp}}
{{cd srtp*}}
{{wget https://issues.asterisk.org/jira/secure/attachment/50065/srtpROC-LE_for_libsrtp1.4.5.patch}}
{{patch -p0 <./srtpROC-LE_for_libsrtp1.4.5.patch}}
{{dpkg-buildpackage -us -uc -nc}}
{{sudo cp libsrtp.* /usr/lib/}}

With sRTP, every packet is signed, so the receiver is able to authenticate each packet. Unauthenticated packets are not uncommon, especially for buggy sRTCP implementations. With the current Asterisk code, sRTP and sRTCP create the same warning message. To debug this in more detail, I added a debug-patch which changes this and the initial sequence number. With that patch, you do not hear your Asterisk anymore after five seconds, already. In that case, please mention the user-agent (and device used) to be added to the above patch.

If you still hear Asterisk after five seconds, you do not face this issue here. For example, Nokia Series 40 and Asha Software Platform phones are _not_ affected by this issue: No one-way audio. Although these phones created the same warning message, their issue is unrelated to SEQ/ROC because with those phones the cause is related to sRTCP.
@Asterisk-Team, shall I open a new issue for those phones?

Missing: Although I created a patch for Asterisk12/chan_sip as well, I did not create a patch for Asterisk12/pjsip. If anyone requires this, please, say so.

By: Alexander Traud (traud) 2014-07-25 06:10:51.690-0500

Updated the patch for the [latest release|https://github.com/cisco/libsrtp/releases], because [AES-IN|https://en.wikipedia.org/wiki/AES_instruction_set] was added. I used the following commands to compile libsrtp, in Ubuntu 14.04 LTS:{noformat}
sudo apt install build-essential libssl-dev
wget github.com/cisco/libsrtp/archive/v2.tar.gz
tar -zxf v2.tar.gz
cd ./libsrtp-*
wget issues.asterisk.org/jira/secure/attachment/59069/srtpROC-LE_for_libsrtp2.3.x.patch
patch -p0 <./srtpROC-LE_for_libsrtp2.3.x.patch
./configure --disable-debug --disable-stdout --enable-openssl
make shared_library
sudo make install{noformat}

By: Matt Jordan (mjordan) 2015-02-25 16:05:59.457-0600

[~traud]: Given that {{libsrtp}} has fixed most of the rollover issues in the recent releases from Github, do you think its still worthwhile to have this patch merged?

If so, if you'd like to put it up for review on Review Board, that might help speed it along.

By: Alexander Traud (traud) 2015-05-04 07:11:45.348-0500

Thanks to [the community|https://github.com/cisco/libsrtp/issues/29], I was able to enhance the filter, so all Nokia Symbian/S60 are recognized now. Furthermore, I added/updated the patches for the latest releases (Asterisk 13, libsrtp 1.5, and libsrtp2-dev).

[~mjordan] because I was not able to find any related changes on libsrtp/GitHub, yet, which fixes are you about? The Asterisk patches require a switch/patch within the libsrtp library. That patch is attached here to this issue, but is not included in libsrtp. It got rejected. However, because I did not understand why, I was not able improve the patch and/or persuade the libsrtp maintainers further. If somebody is interested in these patches (which are about Nokia Symbian/S60 devices only), please, take over and continue!

Until then, we could incorporate parts of the debug patch into Asterisk: For example with Nokia Series 40 (and many other platforms), that unprotect warning happens not for audio/voice (RTP) but statistical (RTCP) messages. With the more precise warning from the debug patch, this might help others to investigate that (different) issue/cause further. Interested? Then, I spin-off that change about the warning message(s) and go through review.

By: Hunter Stevens (onebree) 2015-12-28 12:40:17.627-0600

Is this still an issue for Asterisk 13.6 (and upcoming 13.7)?

By: Alexander Traud (traud) 2017-09-18 10:18:02.611-0500

This issue was about Nokia Mobile Phones and especially those using the operating system Symbian/S60. The fault was within that implementation, not in libSRTP, not in Asterisk. The last phone model based on that operating system was released five years ago in June 2012. Therefore, I am closing this issue by updating the patch for libSRTP versions 1.6, 2.0, and 2.1.

Furthermore, I changed the warning message in Asterisk to signal whether audio/voice (RTP) or statistical (RTCP) messages are affected. That change splits-off the issue of Nokia Series 40 based phones which faced the same warning message when it came to RTCP. The last phone model based on that operating system was released four years ago in September 2013.

If you still face that issue with other VoIP/SIP phones, please, create a new issue report and mention the phone (brand, model, and its firmware version).

By: Friendly Automation (friendly-automation) 2017-09-21 11:37:20.382-0500

Change 6524 merged by Jenkins2:
res_srtp: lower log level of auth failures

[https://gerrit.asterisk.org/6524|https://gerrit.asterisk.org/6524]

By: Friendly Automation (friendly-automation) 2017-09-21 12:00:02.445-0500

Change 6525 merged by Jenkins2:
res_srtp: lower log level of auth failures

[https://gerrit.asterisk.org/6525|https://gerrit.asterisk.org/6525]

By: Friendly Automation (friendly-automation) 2017-09-21 12:00:56.258-0500

Change 6523 merged by Jenkins2:
res_srtp: lower log level of auth failures

[https://gerrit.asterisk.org/6523|https://gerrit.asterisk.org/6523]

By: Friendly Automation (friendly-automation) 2017-09-21 12:10:11.036-0500

Change 6521 merged by Jenkins2:
res_srtp: lower log level of auth failures

[https://gerrit.asterisk.org/6521|https://gerrit.asterisk.org/6521]

By: Alexander Traud (traud) 2020-05-22 05:49:09.458-0500

Updating the patch for Asterisk 13 LTS to be compatible with my own [AES-256 patch|ASTERISK-26190], plus upgrading the patch for Asterisk 16 LTS.