Summary:	ASTERISK-13697: chan_iax2.c: Packet Decrypt Failed! encrypted IAX2 during packet loss causes hangup and end of call
Reporter:	Steve Lang (stevenla)	Labels:
Date Opened:	2009-03-04 22:20:42.000-0600	Date Closed:	2009-03-11 12:40:12
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_iax2
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When using an encrypted IAX2 session and the call encounters normal packet loss, at the point the packet loss occures the error log places the errors below in the error and the call is unrecoverable and hangs up   using the same configuration while turning off encryption the problem no longer occures -----------Cut------------------ .. .. .. .. [Mar  2 18:11:04] NOTICE[4477] chan_iax2.c: Packet Decrypt Failed! [Mar  2 18:11:05] NOTICE[4477] chan_iax2.c: Packet Decrypt Failed! [Mar  2 18:11:05] NOTICE[4479] chan_iax2.c: Packet Decrypt Failed! [Mar  2 18:11:14] NOTICE[4483] chan_iax2.c: Packet Decrypt Failed! [Mar  2 18:11:14] NOTICE[4484] chan_iax2.c: Packet Decrypt Failed! [Mar  2 18:11:15] NOTICE[4481] chan_iax2.c: Packet Decrypt Failed! [Mar  2 18:11:15] NOTICE[4479] chan_iax2.c: Packet Decrypt Failed! [Mar  2 18:11:15] NOTICE[4480] chan_iax2.c: Packet Decrypt Failed! [Mar  2 18:11:24] NOTICE[4483] chan_iax2.c: Packet Decrypt Failed! [Mar  2 18:11:24] NOTICE[4484] chan_iax2.c: Packet Decrypt Failed! [Mar  2 18:11:25] NOTICE[4481] chan_iax2.c: Packet Decrypt Failed! [Mar  2 18:11:25] WARNING[4478] chan_iax2.c: Max retries exceeded to host xx.xx.xx.xx on IAX2/XXXXXX.ip-16384 (type = 6, subclass = 2, ts=630048, seqno=184) ----------------Cut---------------- ****** ADDITIONAL INFORMATION ****** svn co http://svn.digium.com/svn/asterisk/branches/1.4 [^] [^] ./asterisk-1.4-vanilla Installed Asterisk SVN-branch-1.4-r179468 Also tested this version with 1.6 on the remote end and the above svn on my end and had the same results. Tested with Asterisk 1.6.0.5 on both ends and had the same results.
Comments:	By: David Vossel (dvossel) 2009-03-06 13:59:58.000-0600 I'm able to reproduce the issue.  Thanks for opening up a new report! By: Digium Subversion (svnbot) 2009-03-11 12:25:33 Repository: asterisk Revision: 181340 U   branches/1.4/channels/chan_iax2.c U   branches/1.4/channels/iax2-parser.h ------------------------------------------------------------------------ r181340 | dvossel | 2009-03-11 12:25:31 -0500 (Wed, 11 Mar 2009) | 11 lines encrypted IAX2 during packet loss causes decryption to fail on retransmitted frames If an iax channel is encrypted, and a retransmit frame is sent, that packet's iseqno is updated while it is encrypted.  This causes the entire frame to be corrupted.  When the corrupted frame is sent, the other side decrypts it and sends a VNAK back because the decrypted frame doesn't make any sense.  When we get the VNAK, we look through the sent queue and send the same corrupted frame causing a loop.  To fix this, encrypted frames requiring retransmission are decrypted, updated, then re-encrypted.  Since key-rotation may change the key held by the pvt struct, the keys used for encryption/decryption are held within the iax_frame to guarantee they remain correct. (closes issue ASTERISK-13697) Reported by: stevenla Tested by: dvossel Review: http://reviewboard.digium.com/r/192/ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=181340 By: Digium Subversion (svnbot) 2009-03-11 12:34:58 Repository: asterisk Revision: 181371 _U  trunk/ U   trunk/channels/chan_iax2.c U   trunk/channels/iax2-parser.h ------------------------------------------------------------------------ r181371 | dvossel | 2009-03-11 12:34:58 -0500 (Wed, 11 Mar 2009) | 17 lines Merged revisions 181340 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........  r181340 | dvossel | 2009-03-11 12:25:31 -0500 (Wed, 11 Mar 2009) | 11 lines    encrypted IAX2 during packet loss causes decryption to fail on retransmitted frames    If an iax channel is encrypted, and a retransmit frame is sent, that packet's iseqno is updated while it is encrypted.  This causes the entire frame to be corrupted.  When the corrupted frame is sent, the other side decrypts it and sends a VNAK back because the decrypted frame doesn't make any sense.  When we get the VNAK, we look through the sent queue and send the same corrupted frame causing a loop.  To fix this, encrypted frames requiring retransmission are decrypted, updated, then re-encrypted.  Since key-rotation may change the key held by the pvt struct, the keys used for encryption/decryption are held within the iax_frame to guarantee they remain correct.    (closes issue ASTERISK-13697)  Reported by: stevenla  Tested by: dvossel    Review: http://reviewboard.digium.com/r/192/ ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=181371 By: Digium Subversion (svnbot) 2009-03-11 12:37:26 Repository: asterisk Revision: 181372 _U  branches/1.6.0/ U   branches/1.6.0/channels/chan_iax2.c U   branches/1.6.0/channels/iax2-parser.h ------------------------------------------------------------------------ r181372 | dvossel | 2009-03-11 12:37:25 -0500 (Wed, 11 Mar 2009) | 24 lines Merged revisions 181371 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................  r181371 | dvossel | 2009-03-11 12:34:57 -0500 (Wed, 11 Mar 2009) | 17 lines    Merged revisions 181340 via svnmerge from  https://origsvn.digium.com/svn/asterisk/branches/1.4    ........    r181340 | dvossel | 2009-03-11 12:25:31 -0500 (Wed, 11 Mar 2009) | 11 lines        encrypted IAX2 during packet loss causes decryption to fail on retransmitted frames        If an iax channel is encrypted, and a retransmit frame is sent, that packet's iseqno is updated while it is encrypted.  This causes the entire frame to be corrupted.  When the corrupted frame is sent, the other side decrypts it and sends a VNAK back because the decrypted frame doesn't make any sense.  When we get the VNAK, we look through the sent queue and send the same corrupted frame causing a loop.  To fix this, encrypted frames requiring retransmission are decrypted, updated, then re-encrypted.  Since key-rotation may change the key held by the pvt struct, the keys used for encryption/decryption are held within the iax_frame to guarantee they remain correct.        (closes issue ASTERISK-13697)    Reported by: stevenla    Tested by: dvossel        Review: http://reviewboard.digium.com/r/192/  ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=181372 By: Digium Subversion (svnbot) 2009-03-11 12:40:11 Repository: asterisk Revision: 181373 _U  branches/1.6.1/ U   branches/1.6.1/channels/chan_iax2.c U   branches/1.6.1/channels/iax2-parser.h ------------------------------------------------------------------------ r181373 | dvossel | 2009-03-11 12:40:11 -0500 (Wed, 11 Mar 2009) | 24 lines Merged revisions 181371 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................  r181371 | dvossel | 2009-03-11 12:34:57 -0500 (Wed, 11 Mar 2009) | 17 lines    Merged revisions 181340 via svnmerge from  https://origsvn.digium.com/svn/asterisk/branches/1.4    ........    r181340 | dvossel | 2009-03-11 12:25:31 -0500 (Wed, 11 Mar 2009) | 11 lines        encrypted IAX2 during packet loss causes decryption to fail on retransmitted frames        If an iax channel is encrypted, and a retransmit frame is sent, that packet's iseqno is updated while it is encrypted.  This causes the entire frame to be corrupted.  When the corrupted frame is sent, the other side decrypts it and sends a VNAK back because the decrypted frame doesn't make any sense.  When we get the VNAK, we look through the sent queue and send the same corrupted frame causing a loop.  To fix this, encrypted frames requiring retransmission are decrypted, updated, then re-encrypted.  Since key-rotation may change the key held by the pvt struct, the keys used for encryption/decryption are held within the iax_frame to guarantee they remain correct.        (closes issue ASTERISK-13697)    Reported by: stevenla    Tested by: dvossel        Review: http://reviewboard.digium.com/r/192/  ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=181373