[asterisk-bugs] [JIRA] (ASTERISK-16898) SRTP unprotect: authentication failure when RTP sequence number switches from 65535 -> 0

[Alexander Traud (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-16898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Traud updated ASTERISK-16898:
---------------------------------------

    Attachment: srtpROC-Debug_for_Asterisk11.patch
                srtpROC-LE_for_libsrtpHEAD.patch
                srtpROC-LE_for_libsrtp1.4.5.patch
                srtpROC-LE_for_Asterisk12.patch
                srtpROC-LE_for_Asterisk11.patch

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:
{{apt-get source srtp}}
{{cd srtp*}}
{{wget https://issues.asterisk.org/jira/secure/attachment/44499/srtpROC-LE_for_libsrtp1.4.5.patch}}
{{patch -p <./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.

> SRTP unprotect: authentication failure when RTP sequence number switches from 65535 -> 0
> ----------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-16898
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-16898
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/SRTP
>            Reporter: Marcello Ceschia
>         Attachments: srtpROC-Debug_for_Asterisk11.patch, srtpROC-LE_for_Asterisk11.patch, srtpROC-LE_for_Asterisk12.patch, srtpROC-LE_for_libsrtp1.4.5.patch, srtpROC-LE_for_libsrtpHEAD.patch
>
>
> [Jan 19 09:29:34] WARNING[9825] res_srtp.c: SRTP unprotect: authentication failure
> Useragent    : Nokia RM-530 052.005
> Prim.Transp. : TLS
> ****** ADDITIONAL INFORMATION ******
> Depending on the initialze sequence number, the audio stream will become one way.
> I did several tests with the same result always.



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